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I. INTRODUCTION 


Moe GOENERAL 

Combat is a complex, multi-dimensional process, the 
nature of which defies simple description. In its broadest 
sense, this process is divided into land, sea, and aic 
categories. The Army, for its part, focusing its attention 
on the aiz/land battle, subdivides the process further into 
Combat, Combat Support, and Combat Service Support 
functions. While it is generally recognized that a total 
picture of combat cannot be gained by looking at any single 
Subdivision of the process, this segmentation overlays a 
conceptual framework that brings with it a degree of clarity 
necessary for analysis purposes. 

Computer Simulaticns modeliing the air/land battle have 
naturally evolved along these segmented paths. They have, 
however, become so functionalized that they exist today as 
parallel and completely separate worlds seeking to model the 
same phenomenon. The degree to which this segmentation has 
developed was a natural consequence both of hardware 
limitations imposed by older generation computers, and by 


the very complexity of the combat process itself. 
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Modellers, in attempting to present a "total" picture of 
comba«, have erected bridges between these paths with 
varying degrees of success. These pridgées generally take 
*+he form of a Lanchester equation. In practice, a modeller 
concentratss on one path seeking resolution while portraying 
necessary parallel processes in this simplified mathematical 
form. This technigue permits the modeller to Capture at 
least some measure of the interaction of these paths on 
battle outcome, without necessitating the use of an 
unrealistic amount of computer time. 

The direct consequence of this situation is that while 
usually answering questions directed at some particular 
segment, and amply answering the questions of who, what, and 
when at the interface points between paths, such nodels do 
not achieve the sharpened focus needed to answer the where, 
how, and why of the total process. Perhaps this last set of 
questions is avoided because the answer to them requires 
modelling command logic and synergistic interplay difficult 
20 caDture and quite conceivably bevond the scope of any one 
model's charter. At any rate, the loss of this detail 
prevents one from really answering basic juestions as to the 


effectiveness and workability of the combined "total" 


15 





process. In essence, the fundamental guestion, "Can it be 


Gone?", is never adequately answered. 


Eee LOGISTICS MODELS 

Current logistics models then, although running the 
gamut from high level, high resolution simulations to low 
level, low resolution Simulations, must be characterized, in 
accordance? with the above arguments, as single dimensional 
models. For, operating independentiy of any combat model, 
logiszics models must generate the demands they respond to 
‘n some "artificial" way either externally or internally. 
Externally, data generated from a combat model is converted 
to some record of expenditures and front-ended into the 
model as a sequence of events. iInternaliy, the combat 
process is expressed by some form of Lanchester equation 
which dynamically generates specific requirements within the 
con+2xt of the model itself. Output from these models is 
then d2signed to provide a record of activities completed 
Over time as a measurement of an organization's ability to 
respond to a varied reguizrements load. Logistics 
effectiveness is then examined in aggregated terms, such as 
sons delivered per day, or miles travelled per day. Details 
or interplay between the combat and logistical processes ars 


generally not available. 
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dith the development of the Simuiation of Tactical 
Alternative Responses (STAR) model at the Naval Postgraduate 
School (NPS), logisticians have been given a uniguse 
opportunity to investigate this dynamic interaction between 
combat and logistical processes at the most critical 
Mmmerice, che battlefield. Since its initial coding in 1978, 
the model has been continually expanded to include an ever 
widening horizon of combat functions. Several preliminary 
attempts have been made to integrate logistics into the 


model, but as yet, little logistics is played. 


See lo ESiS OBJECTIVES 

In light of the above considerations, a goal of 
developing a rudimentary high resolution logistics nodule 
waS established, with the ultimate aim of the project being 
its eventual integration into the STAR model. After some 
consideration, the preject's goal was redafined further and 
effort was centered on the development of an ammunition 
(Class V) model within a combat battalion. Ammunition was 
chosen both because of its critical impact on the 
battlefield and because the logic developed for this class 
of supply could easily be expanded to other classes. Such 


an attempt would represent at least a first step toward 


ue 





capturing the subtle interaction petween the combat and 
Beguseical processes. The project's plannd approach was to 
have included: 

e A review of previcus work done at NPS in the area of 
resupply. 

e A review of of existing ammunition resupply models 
currently in use within the Army community. 

e Familiarization with the workings of the STAR model with 
the objective of identifying the logical interface 
points for a logistics nodule. 

e The design of an ammunition resupply model written in 
SIMSCRIPT II.5 that simulates the resupply process 
within a combat battalion. 

e Integration of this logistics model into STAR at the 
appropriate points so that STAR generated data such as 
ammunition expended, vehicles killed, et cetera, would 
Peewidae a driver for the) logistics module. 

e Incorporation of the information provided by the 
logistics module into the company and battalion 
commander decision logic of the STAR nodel. 
Preliminary forays into the organization, use, and 


operational vicissitudes of the STAR model, however, 
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immediately identified and underscored the primary 
disjuncture between combat and service support models to be 
pace of battle. The plain fact is that the critical tine 
window for analysis of operational effectiveness is 
diffarent for the two types of models. High resolution 
combat models generally focus on the inner workings of a 
battle that may last less than four hours. Logistics 
models, in contrast, operate over time spans ranging from 
three to thirty days. In the current STAR nodel, battles 
g2nerally terminate after three hours, well before the 
logistical network is even alerted for action. Planned 
expansion of the STAR model beyond the brigade battle now 
fought, however, makes the eventual inclusion of logistical 
factors both possible and necessary. 

With these considerations in mind, the initial 
objectives of interfacing directly with the STAR model was 
modified and the planned logistics module was expanded to a 
full stand-alone, high resolution model. Supplementary 
objectives were astablished in order to achieve the 
completeness of a stand-alone model while keeping the 
ultimate objective of eventual interface with STAR in sigh. 


These additional objectives were: 


19 





e Development of a detailed model that responds to 
requests for ammunition resupply, maintains a simplified 
stockage system, and models the movement cf rounds down 
40 the individual weapon. 

e Maintenance of an appropriate level of resolution within 
the model. Eventual integration into the STAR model 

ictates that the resupply process must begin with and 
be based on knowledge of expenditures of a variety of 
ammunitions fired by any number of individual systems. 

e Maintenance of a high degree of flexibility within the 
model. The modél designed must be flexible €nough to 


adapt to the wide variety of tables cf organization and 


equipment that might be played in STAR. 


D. THESIS ORGANIZATION 

Chapter II provides ar overview of the background 
research which went into the formation of this model. It 
includes a brief outline of current Army ammunition resupply 
doctrine, an overview of two of the most current Army 
modeis, and an examination of several past logistics theses 
done at the Naval Postgraduate School. 

Chapter III presents the Logistics Model which is the 


primary focus of this thesis. It provides an overview of 
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model functions and explains the major model assumptions. 
Topics discussed includes the battle scenario, reguests for 
resupply, the distribution of resupply assets, and the 
redistribution of on-hand assets. 

Chapter IV discusses lessons learned in the construction 
of th2 model and outlines future areas of consideration for 
model 2nhancement. 

Appendix A provides an expanded explanation of the 
material mentioned in Chapter III. This section, however, 
presents the material in a form suitable for the reader who 
is familiar with both combat modelling techniques and 
SesocRIPT IT.5. 

Appendix B is a detailed explanation of the model code 
itself. It provides the reader with definitions of all 
entities, sets, attributes, and variables used in the model, 
along with a listing and line by line explanation of the 


computer code written. 
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A. INTRODUCTION 

This chapter presents an overview of the background 
research that influenced the formation of the ammunition 
resupply model. This information is provided both as a 
ready reference for the works investigated and as a means of 
explaining the underlying rationale of many of tne concepts 
later adopted for use in the model. This chapter includes: 
a brief explanation of the current and future Army doctrine 
regarding ammunition resupply; a discussion cf two of the 
Army's most up to date ammunition resupply models, HELAPS 
II, and ARM; and an in depth look at past logistics thesis 


efforts pertinent to this model. 


B. AMMUNITION SUPPORT IN TODAY'S ARMY 

Without sufficient ammunition resources a combat unit's 
effectiveness is degraded and the tactical alternatives 
available to its leaders severely restricted. For this 
reason, a procedure, which first seeks an internal solution 
through the redistribution of assets, and then an external 


solution through resupply, is standard regardless of unit 


Ze 





type. For example, at platoon or company level the 
redistribution of on-hand ammunition assets is standard 
operating procedure at the conclusion of any move, 
regardless if the move is offensive or defensive. 

When ammunition becomes a dwindling resource on a weapon 
the platoon leader is notified, regardiess if the weapon is 
an M-16 or the main gun of an M1 tank. The platoon leader 
then takes appropriate action either by redistributing his 
own platoon resources or requesting resupply from the 
company commander, or both. In a Similar fashion, piatoon 
shortages are examined at the ccmpany level and if necessary 
a resupply request is submitted to battalion. At battalion, 
a support platcon receives requests for resupply from the 
company then issues ammunition from the battalion's assets. 
This support platoon in turn replenishes its stocks from 
either the brigade ammunition transfer point (ATP) or the 
division ammunition supply point (ASP). The aTP and ASP in 
turn are supported by a corps storage area (CSA). A graphic 
representation of a divisicnal ammunition support structure 


1s given in Figure 1. 


The logic that dictates the resupply activity which 


Should take place and where it should take place is the 


es 
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Figure 1: Ammunition Support Structure 


obiective of zhis model. Determination of the correct 
cours? of logistic action at each level of control from che 
indisvidual weapon up is a function of how much is known 
abouct +he situation az any time. This knowledae is 
admittedly imparfect due to tine delays, human error, and 


the stress of battle. To capture the essence of this 


j- 


mpertect information flow, a central concept, Level of Need 





(LON), was developed to mark thresholds for different 
MerivitieS. This concept is explained in detail in Chapter 


eel 


Ge EXISTING ARMY MODELS 

The purpose of this section 1s to present the reader an 
overview of the two most recently developed Army ammunition 
resupply models. The two models are the Human Engineering 
Bapeta tory Ammunition Point Simulation (HELAPS II) and the 
Ammunition Resupply Model (ARM). Aithough other ammunition 
resupply models exist, the two mentioned above depict 
resupply at a level and degree of resolution that directly 
relates to this thesis. The purpose, characteristics, 
assumptions, input, Output, strengths, and weaknesses of 
each model are discussed to provide an overview of the 
ammunition resupply mcdelling capabilities that are 
available today. The information presented in this chaptez 
has been extracted from the referenced literature regarding 
the respective model. 

1. HELAPS_II 

The initial mcdel for discussion is the HELAPS II 

model. This model was developed by Armament Systems Inc., 


Maeeam, Calit., under contract to the US Army Missle and 
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Munitions Center and School, Directorate of Combat 
Developments, Redstone Arsenal, Alabama. HELAPS II is a 
stochastic, event sequenced simulation that is run on a CDC 
6000 series machine with GASP IV simulation language. The 
model simulates the internal operation of an ammunition 
resupply activity (CSA/ASP/ATP) to include the 
transportation system connecting the resupply point witn its 
source of supply and its customers. The model corstrains 
the flow of munitions through realistic delays representing 
the limited capability of material handling Equipment (MHE), 
resupply vehicles (RSV's) and personnel operating in an 
environment susceptibie to delays due to distance, time, 
weather conditions, integrated battle, and iimited 
resources. [Ref. 1] 

a. Purpose 

The HELAPS model is meant to be uséd as an 

analysis tool for evaluating ammunition resupply activity 
dynamics, operational concepts development, TOE 
design/fvalidation and mission area analysis. HELAPS II does 
this by Simulating the movement of resupply vehicles (RSV's) 
from the customer or source element through the 


inprocessing, loading/off-loading operations, outprocessing 
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activities, and then back to their home elements. These 
activities all occur based on a workload generated in a 
realistic comba* scenario. 

b. Characteristics 

The model uses a dynamic, computer, 
force-on-force wargame (ie. JIFFY) to determine the interval 
between resupply convoys by generating expenditures. These 
resupply convoys of up to 15 vehicles are constrained by 
availability of vehicles, distance traveled, enemy attack 
and environmental conditions. When the convoy arrives at 
the resupply point the RSV's are subject to delays caused by 
queues, processing, MHE/pezrsonnel avaiiability, stock 
shortages, enemy attack and environmental conditions. 
Reliability, availability and maintainability (RAM) of 
equipment, along with internal resupply activity policies 
are also considered where applicaple. Once all elements in a 
Bemvoy are out—-processed the convoy returns to its point of 
departure. 

Gos Oudieour tChesrunning sof HELAPS»II information 
is collected concerning personnel activities and equipment 
performance. This information is analyzed to determine the 
Se 1oOwing: 


(1) MHE/personnel utilization and performance. 
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(2) 
(3) 
(4) 


(5) 


(8) 
(7) 
(8) 
(9) 


(19) 


Inprocessing/outprocessing delays. 
Capacities for receipt and issue of munitions. 
Optimal stockage objectives. 

Effects of enemy actions on performance to include: 
(a) Physical layout. 

(b) Security reguirements. 

Distribution of resupply turn-around times. 
Govrmal Mixeot MHEYand RSV'‘'s. 
Impact of RAM on mission performance. 
Effectiveness of operating procedures. 
Adequacy of current or proposed TOE's. 

c. Assumptions 


All models make assumptions that play an 


important role in the results generated and analysis 


performed. The assumptions made in the HELAPS II model are: 


(7) 


(2) 


(3) 


Resupoly requirements for individual weapons are 
Gonsolidated at the firing unit's battalion. 

Ali resupply activities take place on a 24 hour basis. 
Inclement weather, night operations, and enemy 
Suppression degrade performance of the resupply 


activity. 
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Gi5 [talent ne 


Input data needed *o run this simulation 


consists of numerous user entries. Some examples of this 


ioout data are: 


(1) 


(2) 


(3) 


(4) 


(5) 


(6) 


(7) 


(8) 
(9) 


(10) 
(11) 


(12) 


Distances between firing units and resupply 
activities. 
Distribution of ammunition consumption by firing unit 
for the simulation period. 
Numper of personnel available by duty position at the 
resupply activity. 
Amount of stock by type available at the resupply 
activity. 
Assignment of MHE to specific tasks at each resupply 
Ae Payee. 
Distances between inter-activity elements. 
A scenario of enemy activity. 
All start, stop, and pause times. 
Operating procedures for each resuppiy activity. 
Envimpemmental conditions by activity. 
Hes= Nation role. if applicable. 


Stockage levels for each ammunition type. 
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é. Output 


Thies inpuc data will qenerate output data of the 


following nature: 


(1) 


(2) 


(3) 


(4) 


(5) 


Amount of ammunition received and issued at a resupply 
Poin. DY type. 
Start and stop stockage levels by ammunition type. 
Discrate and average turn-around times by RSV/convoy. 
Discrete and average processing times both in and out 
of the resupply point by RSV/convoy. 
Discrete and average nonavailability times by 
equipment type. 

f. Strengths 


The major strengths of HELAPS II are its ability 


to accomplish the follcwing: 


(1) 


(2) 


(3) 


(4) 


Provide a tool to analyze the internal operations of a 
Munitions resupply activity at any level. 

Provide inferences as to the total issue capability of 
a designated TOE. 

Collect data on the number of RSV's and convoys 
required to support a unit in a given scenario. 
Provide refined estimates (ie. mean and statistical 
Ges na DuetoOn) Of the time required for an RSV or 


convoy to resupply a supported unit. 
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(5) 


(6) 


(7) 


Identify the major choke points of a resupply activity 


and simulate the processing of each vehicie through 


hese choke points in séeguence. These choke points 


and the sequence in which they occur are as follows: 


(a) 
(b) 


(Cc) 


(d) 


(9g) 


RSV/convoy iéaves resupply activity. 
RSV/fconvoy is processed by Ammunition Supply 
Officer. 

RSV/fconvoy arrives at resupply activity and is 
in-processed. 

The RSV/convcy moves to its respective loading 
pow. 

Loading/foff-loading takes place. 

RSV/fconvoy leaves and proceeds to an assembly 
area. 


RSV/fconvoy out-processed through activity office. 


(h) RSV/convov returns to initiating activity. 


Give a good evaluation of the effect of enemy activity 


On mission performance by considering the damage and 


destruction of support equipment. 


Provide a good tool for Combat Service Support Mission 


Area Analysis and TOE development. 
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(8) Provide another check on ferformance of the army's MHE 
design standards for handling munitions. 
(9) Look at scenarios under different environmental 
conditions. 
(10) Provide a tool for choosing the optimal location of 
resupply activities at ail levels. 
(11) Identify security shortcomings for different 
scenarios. 
gq. Weaknesses 
The major weaknesses of the model are: 
(1) Munition consumption and threat data bases must be 
developed manually from a force-on-force scenario. 
(2) The model requires extensive computer core memory 
allocation. 
(3) The model is expensive to run. 
2. ARM 
The second model to be analyzed is the Ammunition 
Resupply Model (ARM). ARM is an interactive, event 
Oriented, time sequenced, computer model developed to 
Simulate *he various runctions associated with ammunitior 
resupply from the Corps Storage Area (CSA) down to the 


individual weapon. It was developed by the Combat 
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Operations Analysis Directorate (COA), CASSA, Fort 
Leavenworth, Kansas in March of 1980. ARM is written in 
FORTRAN IV and consists of approximately 3400 lines of code 
that require 144K octal main storage, including the data 
base. Less than 12 CPU seconds are used in processing the 
resupply actions that result from four hours of combat by a 
division size force. [Ref. 2] 
a. Purpose 

ARM's primary role is to assess the capability 
of a given TOE structure to respond to the logistical 
demands placed on it by various ammunition expenditures. 
For model purposes, these expenditures are created by a 
force-on-force model such as the JIFFY wargame. ARM was 
used in this manner to study the ammunition resupply 
capability of alternative division organizations of the 
Division 86 force structure. The model was developed ina 
general form thereby allowing it to be used with most combat 
models. 

db. Characteristics 

ARM controls the flow of ammunition through a 

network based on the capacity of a given number of RSV‘'s and 


supply points. It also controls the flow through the supply 
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network based on MHE availability. The model actually 
forces the network to replace rounds at individual weapons 
at the unit level, and sends trucks back to designated 
resupply points to fill up and return. The functions of 
each truck are broken up into a series of discrete events 
portrayed as subroutines. The model takes each truck 
through a series of these subroutines (with operational 
availability and interdiction considered) in which actions 
are completed and times accumulated. Helicopter resupply, 
interactive command decisions, and tactical realism can be 
incorporated into the model. 
c. Assumptions 
A list of the key assumptions made in ARM are: 

(1) Only high volumeyhigh demand ammunition is addressed. 

(2) Artillery units reload once each hour duriag a battle. 

(3) Aviation units reload upon the return of aan aircraft. 

(4) Ammunition trucks are dedicated to a specific type of 

aAMmunition. 

(5) When a weapon system is lost, all ammunition is lost. 

(6) When a loaded truck is interdicted, the load is lost. 

(7) Helicopter emergency resupply will support only 155mm 

artillery batteries and the resupply originates at the 


ROP. 
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(8) Trucks are sent for refill oniy when empty. 

mee The division portion of the corps heavy iift 
helicopters will not exceed 10 CH-47's. 

(10) The division portion of corps transportation assets 
for ammunition resupply will be one medium truck 
company. This company will haul ammunition directly 
from the CSA to the ATP's and ASP's. 

d. Input 
The input parameters needed for the operation of 
*he model are: 

(1) Number and allocation of ammunition dedicated 
RSV's/fconvoys in the transportation net. 

(2) Record of on-hand ammunition from th2 scenario 
wargame. 

(3) Number of weapons and basic load of each type systen. 

(4) Ammunition hauling capacity of each RSV. 

(5) Stockage level and loading times at each ASP/ATP. 

(6) Key RSV characteristics (ie. speed, RAM). 

(7) Reload times of each weapon. 

@. Output 
epic tmonm the podel CONSIStS Of an audit trail 


of all events accumulated in a series of reports generated 
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masougn a subroutin= Called REPORT. The following is a list 


of output reports available: 


(1) 
(2) 


(3) 


(4) 


(5) 


(1) 


(2) 


(3) 


(4) 


Status of each RSV to include location and load. 
Current ammunition status of each unit. 
Status of each ATP/ASP to include number of MHE 
available, RSV's in queue and the amount of each type 
ammunition on-hand versus initial stockage. 
An interdiction report to include which RSV's ware 
interdicted and the type and amount of ammunition 
lost. 
Emergency resupply information. 

foe Strengths 

The major strengths of ARM are: 

ARM influences the gamer's tactical decisions for 
ammunition logistics by adding scenario generated 
constraints. 
The model can be used to determine what transportation 
assets of the ASP/ATP are reguired to support a given 
scenario. 
ARM models individual RSV'‘s. 
The model gives an indication of the capability of a 


given ammunition resupply system fcr a given scenario. 
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g. Weaknesses 
The principal weaknesses of ARM are: 

(1) ARM does not model the internai operations of the 
ASP/ATP in enough detail. 

(2) The model uses estimated straight line distances 
between firing unit and resupply points instead of 
actual road distances. 

(3) The model requires a manual data base development for 


each scenario. 


Pee LOGISTICS MODEL DEVELOPMENT AT NPS 

The purpose of this section is to examine and discuss 
four previous NPS thesis efforts which modelled aspects of 
Heqgistics. Three of these efforts are directly telated to 
che STAR model. 

Since the development of the STAR model at NPS, 
logistics planners have been given a unigue cpportunity to 
investigate the dynamic interaction between the combat and 
Pues lOgiStics process at the most critical juncture, the 
Meeeltefield. Since its initial coding in 1978, the model 
has been continually expanded to include an ever widening 
horizon of combat functions. Although several attempts have 


been made to integrate logisitics into the model, little 
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Megist-cS 1S cu=rently played. This section will review 
several previous logistics theses written at NPS. Some 
address STAR directly; others do not. In summary, these 
works form part of the evolutionary development of logistics 
modelling at NPS of which this model is a part. Discussion 
of each effort will include: a general description; an 
enumeration of assumptions; a discussion of the modelling 
techniques developed; a discussion of strengths and 
weaknesses of these technigues; and an outline of the nodel 
utility. Some of the concepts developed in these efforts 
are used in this ammunition resupply model; others will be 
valuable for future efforts. 

1. “Simulation and Analysis of Transport in Support of 


a_ Combat _Unit"_by John _&._ Kelley (1978) { kef._3] 

This thesis parametricaily analyzes the mission of 
the support platoon of a U.S. Tank Battalion. The stated 
objectives of the thesis were: to develop an overall 
logistics model that could be integrated into a battalion 
level combat Simulation; to measure the Support Platoon's 
ability to move supplies under varying conditions; and to 


evaluate the impact of simultaneous forces on combat support 


operations. 
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In pursuing these goals, a Monte Carlo simulation of 
+he ammunition resupply process was developed. The use of a 
Mont2 Carlo simulation to capture the interaction of forces 
on the resupply process was a step away from traditional 
network/pipeline analysis normally developed for logistics 
studies. The technique involves the identification and 
isolation of significant variables within a process, 
asSignment of probabilities of occurance to each variable, 
and replication of the process described by these variables 
in order to achieve an expected value outcome. Using this 
technigue, the author was able to focus attention on 
specific aspects of the resupply process, to deliberately 
vary values for the probability of their occurance, and to 
Statistically analyze results for significance. 
a. Assumptions 
The major assumptions made by Kelly in his 
thesis are: 
(1) The ability of a support platoon to provide ammunition 
suppesbt tO che battalion is a direct function of: 
(a) The maximum number of trucks available at any time 
(Drivers assumed always available). 
(b) The maintenance time required. 


(c) The probability of ambush. 


She, 





(2) 


(3) 


(4) 


(5) 


(6) 


(7) 


(8) 


(dad) The probability of kiii given an ambush. 
(¢) The loss of vehicles to ambush. 
(f) The time required to replace lost vehicles. 
Vehicles can make a maximum orf three round trips a day 
co sippiy pomnts. 
Maintenance readiness is evaluted at the end of each 
=rip. Readiness is measured against a fixed 
operationally ready(OR) rate. 
Ammunition is obtained from a CSA located at the 
Division rear. 
Ali vehicles in a convoy are subject to enemy attack. 
Survival of each vehicle is measured against a fixed 
probability of kill. Partial damage and salivage are 
not played. 
Support is being provided to a "pure" tank battalion. 
The effects of each of the parameters measured are 
independent and additive. 
Measure of effectiveness selected: Truckloads moved 
during specified time periods. (3,5,15,30 days) 

b. Method of Evaluation 


Due to the software limitations on the analysis 


packag2s available when the thesis was written, the model 
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limited itself to a consideration of replacement time, 
probability of ambush, number of round trips delivered to 
supply points per day, and maximum number of vehicles 
available. Probability of kill given ambush, and 
probability of a vehicle becoming non-operationaily ready 
were fixed for each Simulation run. The impact of these two 
factors was combined into the mean of the design. 

Having specified those aspects of the resupply 
process critical to the success of the Support Platoon 
mission, a range of prebabilities for success for each of 
the critical parameters was fixed and a number of Monte 
Carlo simulations conducted for each variation. An analysis 
of the results was performed and an exnected value for each 
set of selected probabilities was computed. The analysis 
conducted also measured the effects of each individual 
component, and its interaction with the cther elements. 

As a final demonstration of the methodology, a 
conflict set in a European scenario was developed and a 
Simulation conducted. Values for each of the four critical 
parameters were varied in response to the scenario 
conditions, and in accordance with the judgement of the 


writer. A regression performed on the results fitted a 
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fienea> tMloag2l to the data to check the linear fit of the 
postulated model. Parameters again were varied, results 
tallied, and tested for significance. 

Cc. Strengths 

The study achieved its objective of formulating 
and exercising a resupply simulation within the bounds of 
those parameters hypothesized as being critical. Accepting 
the premise that the factors modelled captured the critical 
essence of the resupply process, the technique used in the 
thesis could be modified and used in a generalized combat 
model to return a value of total tonnage of supplies 
delivered during a specified time period. 

The primary conclusion of the analysis 
conducted, that the probability of enemy attack and the 
physical location of the resupply point were the driving 
forces behind the model, dictates that such parameters be of 
prime importance to any resupply model. 

d. Weaknesses 

The najor weaknesses found in the model are: 

(1) Conceptual limitation to those parameters defined as 
Critical. Use of parameters other than those specified 


and tested in the thesis would seriously weaken the 
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(2) 


(3) 


conclusions made in the thesis and could lead to 
PncOrEectresulcs. 
Current doctrine to include the creation and use of 
Ammunition Transfer Points (ATP's) was not considered. 
Operationally Ready (OR) rates are normally determined 
on a daily basis rather than after each supply trip as 
proposed. 

en, Utili cy 


This model could best be utilized in the 


following manner: 


(1) 


(2) 


The method developed and the results generated by the 
model would best be utilized as a generalized 
constraint to a high resolution combat model or, after 
some data analysis, as logistics coefficients ina 
Lanchester model. 

The major finding of the model was that distance and 
probability of enemy activity were the driving 
parame*ers in the determination of overall mission 
accomplishment. AS such, development of any resupply 
model should consider those parameters identified as 


Serercal in their structure. 
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i li eli ee ee, eee 


This thesis and the follow-on work conducted by 
Wallace and Hagewood after their graduation from NPS formed 
+he basis of what is now the STAR model. This original work 
was d2signed as a high resolution, event sequenced, 
stochastic model of ground combat. The language used was 
SIMSCRIPT II.5. Since much of what was developed is still 
an integral part of the present model, this document is 
Still a vital reference tool. In buiiding the simulation, 
logistics 2ffects were modelled in three ways. These were: 

(1) The use of logistics as an engagement constraint by 
asking the question, "Do I have this ammunition 
en-hand tovfire?" 

(2) The use of logistics as a time constraint by asking 
the question, "Given that I have this ammunition on 
board the tank, what storage compartment is it in, how 
long will it take me to access it and move it to the 
ready rack?" 

(3) The modelling of logisitical methods to create supply 


caches in order to resupply combat elements. 
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Of these three attempts to model the effect of 
logistics on the combat process, only the first, logisitics 
aS an engagement constraint is currently used. The use of 
logistics as a firing constraint was abandoned after the <XM1 
stowed load study was completed. This constraint could 
easily be added to the existing STAR model but at the 
present time such a high degree of resolution is 
inappropriate The modelling of resupply caches was 
abandonned because at that stage of the model's development, 
the contribution of the caches was of marginal value when 
weighted against the time required to prepare the data and 
the CPU time required to execute the logic. Tanks on the 
battlefield were killed, or the battle was ended before 
resupply was necessary and so the logic modelled became 
superfluous. 

Fach of the three attempts to incorporate logistics 
effects however, is worth analyzing in order to gain insight 
into the interplay of forces within STAR, and to gain 
modelling insight thrcecugh access to existing working code. 

a. Methodology 

The general methodology of this model is as 


follows: 
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(1) 


Pemsuopry AS A Fanang Constraint - in this logic, 
ammunition availability is played as a constraint to 
firing. The logic developed tracks on-hand ammunition 
by type for each tank. At the beginning of a firing 
sequence, a round is selected and its on-hand 
availability is screened on a go/no go basis. [In 
implementation, ammunition is modelled at two critical 
junctures, when selecting the ammunition to fire, and 
upon round impact. The first juncture is controlled 
by routine PRIORITY.AND.ROUND.SELECT. This routine 
assesses the relative importance of the target 
currently selected, chooses a preferred round for use 
against the target, and checks to see if the stocks of 
the round are available. In performing this functicrz, 
the routine accesses a matrix called a DANGER STATE 
array to determine the priority of the target, and to 
select the ammuniticn to be fired. Routine 
PRIORITY.AND,ROUND.SELECT then calls routine 
AMMO.CHECK which screens the ammunition attributes of 
the specific tank to determine if the ammunition is 
available. The second juncture occurs at the time the 


round is scheduled to impact. As part of the logic, 
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(2) 


(3) 


routine DECREMENT. AMMO is called to subtract one round 
Of the type Of a@mmunition fired from the tank which 

pa ea. 

Resupply As A Limitation On Firing Time - the logic 
developed for this aspect of logistics was done in 
Support of the XM1 tank stowed load study. It 
modelled the time reguired to physically move rounds 
inside an XM1 in an effort to add a degree of realism 
zo the play by restricting the access to ammunition on 
the tank. This logic modelled the time required to 
move rounds from one of five storage compartments on 
the tank to the ready rack. This level of detail was 
later judged to be unnecessary in the normal use of 
the nodel. 

Resupply - additional work after thesis completion 
attempted to extend ammunition concepts to include the 
movement of supplies from storage areas to resupply 
caches. The focus of this logic was a Supply Officer 
entity who controlled a number of caches in support of 
his unit. These caches are planned pricr to program 
execution. In the execution, a routine PILE.SO.CREATE 


calls a number of subprograms which loads trucks at 
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(1) 


(2) 


(3) 


the ATP (¢vent LOAD. PLAN), moves loads to a 
pre-planned cache site (event MOVEOUT), and offloads 
the ammunition at the site (event OFFLOAD). Resupply 
of the combat vehicles (event UPLOAD) was accomplished 
when the unit withdrew to the location of the cache. 

b. Strengths 

The major strengths of the model are: 

Logistics As An Engagement Constraint - the logic 
developed directly tracks the on-hand balance of 6 
types of ammunition for each weapon system. This is a 
basic start point for any model that hopes to model 
logistics in STAR realistically. 
Resupply As A Limitation To Firing ~- although this 
code proved to be of value in the XM1 stowed load 
study, the decision to turn off the code was more a 
function of lack of utility than absolute uselessness. 
The logic, in fact, provides an immediate tie-in for 
any future modelling of delivery of a resupply of 
rounds to the combat units. 
Other logic developed depicts the loading and 
unloading of supply trucks and combat vehicles, 
creation of caches at pre-designated points, anda 


rudimentary stock control system. 
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Ce. Weaknesses 


The weaknesses of this model were perceived in 


the following areas: 


(1) 


(2) 


There was no overall logic developed to dynamically 
control and integrate logistics play within the model. 
Tanks will continue to fire until ammunition stocks 
are exhausted. Resupply caches are entirely 
pre-programmed and once execution begins, the dynamic 
flow of the battle will not change the creation of 
stocks. 
The assets possessed by @ unit will not influence the 
zactical decision process. Logistics influence is 
iom@iced strictly to fire/no fire control. 

de. ,Use abi ty 


The SIMSCRIPT coding developed is fully and 


immediately integratable into STAR and thus represents an 


excellent start point for any new logistics study. The 


basic STAR model interface points still exist. If future 


STAR logistics modellers understand this logic they will 


Save themselves considerable time and effort. 


The immediate extension of this logic includes 


recognition and use of the current ammunition status <o 
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mewgqer resupply actions. Further extensions include the 
use of ammunition status to modify tactical courses of 
action or to trigger a request ¢o move. 

3. "A_Dynamic Ammunition and Resupply Model _in Support 


of the STAR M 
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This thesis presents a conceptual framework for 
modeling logistics functions within a combat brigade. The 
objective of the thesis was to develop a logical structure 
sor the modelling of ammunition and fuel resupply. It was 
hoped that this logical structure would lay a basis for tne 
future development of detailed logistics logic to be entered 
maico STAR. 

The medium chosen to depict this framework was a 
network diagram. The primary product of the thesis was the 
development of this network and associated parameters 
essential to modelling resupply. Resolution of a fully 
developed model using this logic would depict individual 
trucks carring rounds of ammunition from the brigade trains 
to the combat vehicles. Ammunition would be measured by the 


"box", a generic term used to represent all packaging 


configurations from the individual round to a pallet of 


50 





rounds. Petroleum would be measured in bulk terms only; 


packaged petroleum is not played. 


(1) 


(2) 


(3) 


(4) 


(5) 


a. ASSuUMptions 
The major assumptions made in this model are: 
Battalion trains are located 5 Km and brigade trains 
are located 25 Km behind the FEBA. 
Corps will transport ammunition from the Corps Storage 
Area (CSA) in the Corps Rear Area to the Ammunition 
Supply Points (ASP*s) located in the Division Rear and 
the Ammunition Transfer Points (ATP's) located in each 
of the brigade areas. 
Corps ammunition support to the division will be 
provided by two conventional ammunition companies with 
each company operating two ASP's. 
Capabilities of ammunition points are as follows: 
(a) ASP - Receipt and issue of 2000 short tens of 
ammunition daily. 
(>) ATP - Receipt and issue of 500-600 short tons or 
ammunition daily. 
Only 5 ton trucks are capable of making the round trip 
from the battalion trains to an ASP and back. AFARV's 
and GOER's are limited to trips to/from the ATP's at 


brigade. 
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(6) Vehicles will travel only in convoys. 

(7) Operationally ready rates (OR) are computed once daily 
mecoOrding to che following rates: 

(a) Material Handling Equipment (MHE) - 75% 

(b) Bn Ammo Vehicles - 85% 

b. Characteristics 
The resupply framework was developed around the 

traditional supply MOE of ascertaining the number of 
truckloads of ammunition delivered per unit time. [In 
execution, the network traces the movement of trucks of 
varying dimensions through a network subject to unifornly 
distributed movement and loading times. 

(1) Network Development - the key to the thesis work was 
the development cf the network diagram itself. The 
network depicts the flow of supplies from division and 
brigade storage areas to the bpattaiion trains. 
Central to this concept was the determination of the 
number and characteristics of carriers, arcs, and 
nodes which make up the systen. 

(a) Carrier: the term used to represent the actual 
supply trucks on the network. Each carrier type 


has specific weight and cube limitations. These 
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(D) 


(Cc) 


limitations are used to constrain a vehicle's 
capability to transport ammunition. The carrier 
is the critical focus of the system, since 
determination of the quantity delivered per unit 
time is based on the carrier's successful 
Colpmet i ONnwOretErps tc/Eroumthe supply points. 
Arc: the term used to represent road segments on 
the ground. Ares direct traffic flcw and are used 
to determine straight line travel time between 
points. Load capacity of roads is depicted by 
limitations on vehicle speeds on individual arcs, 
for example, 10 mph over unimproved roads. Road 
congestion, although identified as potentially a 
Major problem, was not explicitly modelled. 

Nodes: these mark points of change within the 
network itself. Two types of nodes were specified, 
load state changes and travel state changes. Load 
State changes mark those locations where 
ammunition is loaded and unloaded. Activity at 
these points is modelled as time delays generated 
from specified distributions. Operationally, these 


delays would be modelled as a function of the 
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(2) 


number of people at the point, the number of MHE 
pieces at the point, the capacity of the carrier, 
and the length of the queue at the resupply 
location. Travel state changes represent those 
points on the network at which direction of travel 
changes. These points represent travel through 
cities, past major intersections, and through 
points of congestion. 
Movement And Load Times - a second key aspect of this 
framework is the concept of time use. All times 
Within the model are assumed to be uniformly 
distributed about a calculated mean. Thus travel tine 
along a stretch of highway is based on the length of 
the roadway and on the assumed speed of the vehicle. 
To this, an induced variability of plus or minus 20% 
was introduced +o allow some further randomization of 
vehicle times. Load/unload times were based on an 
assumed loading time for the particular load on a 
Specific cargo carrier. Thus, ammunition cargo varied 
py the “box” configuration to be handled, while fuel 
loading varied in accordance with the load capacity of 


the pump assumed to be at the location. 
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(2) 


Gy  Strengens 
The strong points of this model are: 

The thesis successfully established a network diagram 

which adequately captures the varicus activities which 

make up the supply chain. The example illustrated in 
the thesis is in generalized enough terms to be easily 
adaptable to any particular setup. 

Although designed for a FORTRAN Simulation, the 

descriptors used to model the flow of the network can 

be adapted to any Simulation language. These critical 
descriptors and the information they convey aré as 
follows: 

(a) Arcs: length of road segment; type of road 
(unimproved,etc.); average vehicle speed on the 
road; amount of congestion on the road. 

(b) Nodes: type (road junction,supply point,town,etc) ; 
average delay time expected. 

(fe) Carriers: 

® AW8unition Carriers - type, max cargo 
weight, Operationally ready status; location; 
amount of cargo on board; type of cargo on board; 


Un . 
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e Petroleum Carriers - type; fuel carried; 
amount carried; gallon capacity; pump rate. 
(d) "BOX" of Ammo: weight of package; volume of 
package; number of rounds/box. 
d. Weaknesses 
Some of the major weaknesses perceived by the 
authors in the model are: 

(1) In briefly outlining assumptions, locations of support 
units were discussed in terms of fixed distances 
rather than as envisioned in the more flexible design 
deezrime Called for. In fact, presen doctrine calls 
for the battalion trains to normally divide assets 
between two locations, the combat trains and the field 
*rains. Combat trains are located 5-7 Km behind the 
FEBA while the field trains are located 10-15 Ka 
behind the FEBA. The composition of either is 
flexible; however, the bulk of ammunition supplies is 
normally maintained at the field trains. Brigade 
trains are normally located 15-25 Km behind the FEBA 
and so could conceivably be co-located with the 
battalion trains. The central considerations which 


dictate the location of these facilities is the 


56 





(2) 


(3) 


ey) 


(5) 


(6) 


(7) 


Bount 


mission of the unit and the range of enemy mediun 
artillery. 
The vehicle load times for various ammunition types 
were established for illustrative purposes. More 
realistic distributions must be developed for actual 
applications. 
No provisions were made to nodel hostile action on the 
network. 
No queue was explicitly established at any supply 
point. 
The network was self-contained and designed to model 
only the movement of battalion trucks on the network. 
Once a resupply vehicle arrived at the pattalion 
trains, resupply was considered completed. No attempt 
was made to model the loading of ammunition on combat 
vehicles. 
There was no decision logic developed to dynamically 
control the network or to react to a change command 
once the vehicles were set in motion. 

See eruta lity 

The network designed is an excellent starting 


for the development of resupply logic at the 
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battaliony/sbrigade level. The detailed development of the 
essential elements of this network is a first cut at molding 


+he disparate elements of resupply into a coherent process. 


Model" _by_D.G._Kirby_and_ D.P._ Schultz (1980) [ Ref. 
This thesis was the first attempt to integrate the 
effect of logistics in the STAR model. The objective of the 
work was to design a broad flowchart orf the programming 
logic required to model logistics and to investigate a means 
of modelling the command and control decision processes 
which overlay this process. The authors limited their 
discussion to the resupply of petroleum and ammunition. Ina 
depicting this development, the authors utilized the 
Software Decision and Documentation Language (SDDL) which 
outlines the logic of the program in the form of a detailed 
meowchart. 
a. Assumptions 
The major assumptions made py Kirby and Schultz 
are: 
(1) The Battalion Support Platoon is solely responsible 


for battalion resupply. Ammunition is obtained fron 
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Soca ne AT® Gumeby DISCOM, or from the ASP run by 
corps. Petroleum 1s obtained from DISCOM tankers 
spotted in the Brigade Supply Area. 

(2) Resupply can be accomplished either by moving supplies 
forward to the combat vehicles (unit resupply), or by 
pre-positioning ammunition at specified locations 
(Cache). 

(3) Supply vehicles carry homogeneous loads. No 
cross-leveling of cargo between supply trucks is 
permitted. 

(4) Ammunition will not be redistributed between elements 
Ewa Un Le . 

b. Methodology 
The logic designed can be divided into three 
categories: 

(1) Command logic within a battalion. 

fm) Unit resupply logic. 

(3) Supply point resupply logic. 

The critical development by the authors was the 
design of the command decision logic; rlow for tae other two 
Categories was relatively transparent. Command logic is used 


primarily to evaiuate the current supply situation and to 
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Mee-eeN° ne 2 Driority for resupply. The key te this logic 


Wits in the development of the concept of Level of Need 


Level of Need (LON) is a categorical structure 
through which the resupply situation of a unit is expressed. 
It represents the ratio of supplies on-hand to the total 
capacity of the unit. The auchors define four Levels of 
mertteecull, want, approaching critical, and critical. LON 
is computed for each firing system with regard to its 
primary ammunition and its fuel status only. The lowest 
Mee y coaputed for either determines the overall LON for 
the weapon system. At the platoon, this logic models the 
platoon lead2r examining the LON of each of his vehicles. 
The platoon is then assigned an LON based on the category it 
falls under. This platoon logic is duplicated at each 
Semeany, Dattalion, and brigade in the resupply chain 
therearter. 

Decision logic for resupply uses this LON and 
combines it with a consideration of supplies available for 
issue and an evaluation of the suppression level at the unit 
being resupplied. A listing of all requests is then 


Pmemor>.iZed in accordance with the above criteria. Ties are 
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Peoken in favor of the unit with the greatest aumber of 


weapon systems alive, the thought being that maximization of 
available combat power is a commanders first concern. 
c. S*rengths 

The thesis clearly outlines those essentiais 
necessary for the modelling of resupply. Although no code 
was daveloped, the flow diagram deveioped illuminates the 
path +o be taken. Decisicn logic is always a difficult area 
*o mod2l. Development by the authors of a conceptual basis 
for this process is invaluable. By specifying the urgency of 
need through th2 concept of LON the authors made the 
=esupply decision logic workable. This procedure for 
MeeOri<izing resupply efforts based on the factors 
enumerated outlines a clear and realistic nodel of the 
commander's thought process. 

d. Weaknesses 

Presentation of a combined LON depicting the 
fuel and ammunition situation is unrealistic. The need for 
ammunition and fuel must be assessed separately as each 
impacts on the tactical situation in a different manner. In 
Stee, a further sub-division within these categories as to 


type of fuel and type of ammunition would present a clearer 
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pagmemore realistic picture upon which to base tactical 
decisions. The method of combining LON at platoon and above 
based on a predominant LON and on a subjective assessment of 
the relative importance of tactical systems is also 
unrealistic. Again a sub-division of information into types 
of ammunition and types of fuel needed would add a clearer 
and more realistic dimension to the problem play. Failure 
of the authors to develop logic for the redistribution of 
on-hand assets is unrealistic. Addition of such logic would 
present a truer picture of the real process within units. 
Lastly, consolidation of ammunition on-hand at the platoon 
level and above must include a consolidated count of all 
assets on-hand, including reserve assets. Failure to do 
this would again cause decisions to be based on unrealistic 
data. 
Sood La ey 

This thesis illuminates the path of development 
for future logistic modelling in STAR. The flowcharts 
presented are detailed and thorough. They totally explain 
the resupply network. This concept of modelling the 
decision framework overlaying the supply network, while 
needing significant revisions, steers future efforts in the 


megat direction. 
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Wa eos DEsCREPTLON 


Pee LNTRODUCTION 

This chapter presents an overview ot the ammunition 
resupply model developed for this thesis. It discusses each 
of its parts in general terms and lists its major 
assumptions. A detailed discussion of the model, *o include 
an explanation of the SIMSCRIPT JI.5 programming language 
and he model code developed is presented in Appendicies A 
and B. 

The resupply model presented in this thesis is a 
stochastic, discrete-event Simulation implemented in tae 
SIMSCRIPT II.5 programming language depicting ammunition 
resupply procedures within a combat battaiion. The basic 
structure of the ammunition support flow is taken from Army 
Field Manual 9-6, Ammunition Service in the Theatre of 
Operations (Ref. 7]. The model is designed to provide a 
flexible framework within which the user may specify the 
Tables of Organization and Eguipment to be played and the 
critical resupply levels which will result in a resupply 


action. In its present form the model can play an unlimited 
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number of weapon systems and ammunition types, however, each 
individual system is limited to a maximum of 6 ammunition 
types. 

Section B of this chapter discusses the battle used in 
generating the data for the model. 

Section C explains how ammunition expenditures are 
tracked from the weapcn to battalion and how such 
expenditures thereby trigger resupply action by the chain of 
command. 

Section D discusses the resupply iogic used at each 
level of command in evaluating the availability of on-hand 
ammunition and determining both the quantities released and 
priority of resupply. 

Section E explains how the redistribution of on-hand 


ammunition assets is modelled and when it takes place. 


wee Las BATTLE 

The purpose of the battle in this model is to generate 
Tequirements that will force a response from the ammunition 
resupply logic developed. Initially, the authors intended 
to use the STAR model as a source for input data, since a 
record of ammunition expenditures is normally generated as 


Part Of its output. In the present configuraticn of STAR, 
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however, the battle terminates well before ammunition 
resupply ever becomes critical, so a direct tie-in to the 
model was deemed impractical. An alternate proposal for 
generating data from multiple STAR runs was also rejected as 
+00 cumbersone. 

Instead, it was decided to generate the needed data 
*hrough the use of Lanchester equations and Monte Carlo 
technigues. Admittedly, considerable realism and resolution 
are lost in doing this, but the simplification permits the 
generation of necessary data without the use of a 
prohibitive amount of computer time exercising the STAR 
model. It is important to keep in mind throughout the model 
that the battle generated is unrealistic and is used solely 
as an expedient +o generate data for the logistics model. 

Examples of the types of data generated by the battle 
for use in the resupply model area: 

e Ammunition Expenditures Over A Given Time Period - this 
data is generated for each weapon system in the battle 
and each ammunition type it might possess. 

e Damaged And Destroyed Vehicles - combat and resupply 
vehicles are periodically checked for battle damage by 


evaluating random number draws against a set of damage 
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probabilities assigned by the user to each type of biue 
vehicle in th2 model. 

e Movement Of Units - within the present model movenent of 
company units is accomplished on a random basis. The 
purpose of such moves is solely to execute the model's 
Bedisctribution logic. 

The major assumpticns underpinning the vpattle's 
architecture are: 

e Battles are fought for 6 hours a day. The start time of 
the battle is determined by a random draw. 

e Each weapon type of a weapon system has a rate of fire 
assigned through user input. However, the same weapon 
on a different system can be assigned a different rate 
of fire if the user so desires. 

e Ammunition expenditures are generated in the model by 
evaluating random number draws against weapon systen 
probabilities of fire for each armament. Expenditures 
are then computed by multiplying the rate of fire for 
that eee times the elapsed battle time for that 
BPatticular day. 

e Combat vehicle damage is assigned on a random basis over 


mouG types of kilis :; firepower kilis, mobility kills, 
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mobility/firepower kills, and catastrophic kills. For 
all types of damage except firepower kills, ammunition 
on board that vehicle is considered lost. Ammunition 
assets belonging to a vehicle that sustains a firepower 
kill are assumed undamaged, and are immediately 
redistributed to the other fighting vehicies within that 
fighting system's respective platoon. 

e Movement is restricted to company units and can take 


place only after that day's battle. 


Bee REQUESTS »FOR RESUPPLY 

Expenditures of ammunition by individual weapons form 
the basis of resupply activity in the model. Key to this 
process is a concept called level of need (LON). A level of 
need is evaluated for each ammunition carried by a combat 
entity in the simulation. These individual vehicle LON's 
are aggregated to form LON's for each platoon and company in 
the model. The purpose of the LON is to provide a measure 
of the urgency of need a weapon or unit has for a particular 
ammunition type. An entity's LON is updated over uniformly 
distributed time intervals independently of other vehicles 
or units in the model. This technique was implemented in 


order to capture some sense of the imperfect information 
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*hat is inevitably generated and passed in any supply 
Ewet=m. The purpose of this section is to explain this 
resupply request process and to discuss the effect of and 
reaction to the imperfect information by the chain of 


command. 


Level of need is a concept that was originally 
developed by Kirby and Schultz in March of 1980. The basic 
idea they developed is adopted for use in this model with 
some major alterations. The concept of a level of need was 
adopted because it represents a single unifying idea that 
Will allow the expansion cf this model to all classes of 
supply. 

Level of need describes the urgency of need a weapon 
has for a particular type of ammunition. This urgency is 
then sequentially passed to and evaluated at each level in 
the chain of command until a level is reached which can 
respond appropriately. A separate LON is computed for an 
ammunition type at the weapon, platoon, company, and so on 
With information from each lower level being fed into the 
computation of the LON of its immediate superior. [In 
effect, this forces each level to respond to the battle 


Pro W . 
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The actual value for an LON iS assigned based on the 
measured percentage of fill (amount on-hand / base load) of 
an ammunition type at a particular moment. The essential 
idea is to have threshold values for the percent f111 of an 
ammunition type which will trigger a leader's actions. fhe 
benchmark for this computation is called a base load for 
that ammunition type. An LON continually charges as 
individual weapon entities, seach with its own ammunition 
configuration, are damaged or destroyed. 

At the weapon level, base load 1s equal to the 
initial stowed load fcr the particular ammunition in the 
weapon system. This load can be different for each weapon 
system within a platoon. An ammunition's base load, for a 
platoon, is equal to the sum of all stowed loads of alive 
systems in the platoon possessing that ammunition type. A 
company's base load is, in turn, determined by summing over 
the base loads within its platoons and so forth. 

Level of need within the model is divided into 5 
categories, the ¢«hresholds of which are controlled by user 
input. These 5 categories are defined as follows: 

a. Full ("5") - a weapon or unit has enough of its base 
load of an ammunition on-hand that no resupply is 


warranted for that ammunition type. 
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D- 


Want ("4") = the weapon or unit's on-hand load is below 
pult, DUE 2S Not in a position to jeopardize the 
mission. Reaching a "WANT" LON initiates a resupply 
action at the lowest priority. 

Approaching Critical ("3") - this level implies that 
the weapon or unit's on-hand ammunition is at a level 
warranting a higher urgency of need for resupply anda 
greater priority for fill when ammunition becomes 
available than the "WANT" level. 

Critical ("2") =- the weapon or unit's on-hand 
aMMmunition has reached a levei that seriously endangers 
mission accomplishment to the point that survival of 
the weapon or unit may become a problem. Immediate 
action is essential. 

Empty ("7") - the weapon or unit has no on-hand balance 
for a particular ammunition typs and is no longer able 
*o perform its mission. 


Weapon and unit LON thresholds for the above 


categories are left as user inputs and must be supplied by 
the user for each combination of ammunition type and level 
of command. tank then has different threshceld values for 


the several ammunition types it carries. This corresponds 
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+o placing degrees of importance on types of ammunition. 
So, while a tank might be considered critical for APDS 
rounds when it reaches 30% of its stowed load, it might not 
become critical for 50 caliber ammunition until it reached 
10% of its stowed load. At the platoon, the thresnold 
values for these same ammunition types would be different 
from «hose of the individual fighting systems. This models 
a platoon leader's wider perspective on a battle Situation. 
This situation is repeated at successively higher levels of 
command. 
2. Requests for Resupply 

The resupply process begins at the weapon system 
where ammunition status is periodically updated. The time 
between updates is determined based on draw from a user 
defined probability distribution. The platoon, for its 
part, periodically updates its own status by obtaining 
information from each of its assigned weapon types. The 
company, in turn, updates its status by obtaining 
information from each of its platoons. The information 
"passed" to each level is that obtained from each entity's 
mos = current update rather than from any scurce of "parfect" 


information. Requests for resupply below company level are 
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limited to those ammunition types for which a vehicle or 
platoon is ampty. These requests alert the next higher 
level to update itsS ammunition Situation and to take action 
appropriate to its level. 

The formality of a resupply requisition is 
introduced at company level where resupply requests from the 
company to battalion are triggered every time a company's 
LON changes for an ammunition type. Quantities requested 
vary in accordance with the assets possessed by the 
requesting entity. 

3. Imperfect Logistics Information 

Information passed during a battle is approximate at 
best. The imperfect nature of this information is a result 
Samuany factors, including: 

a. Estimates of on-hand ammunition made at the weapon 
during combat - It is frequently impossible +o stop and 
count ammunition assets during the heat of an 
engagement; educated guesses are often the rule rather 
than the exception when passing ammunition information. 

Db. Time lapses between resupply requests and delivery of 
requested material - From the time the request is 


forwarded until the delivery of the ammunition, 
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additional resources will be expended and weapon 
systems lost. 

c. Simple counting mistakes. 

Within the model, imperfection of the logistics 
information is induced as follows: 

e Weapon systems update their ammunition LONs periodically 
ax random times within user established minimum and 
Maximum times. Upon request from platoon, the weapon 
system provides its most current count; that is, it 
provides «he information obtained from its own last 
ammunition update. 

e Platoons and companies can obtain their information only 
from their immediate subordinates, again at random tines 
within user specified intervals. This procedure 
duplicates the periodic requests for ammunition updates 
from platoons and companies to their subordinates during 
a battle. Again, the information reported by 2ach 
subordinate level is that obtained from its own last 
update. 

e At the company level, formal resupply reguests are 
created by ammunition tyfe as an ammunition's LON value 


Changes. This corresponds to 4 company periodically 
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reviewing and updating its resupply requests because of 
ammunition expenditures or loss of ammunition due to 
vehicle damage or destruction. The quantity requested 
each time is the guantity which would be required to 
bring a unit back to full base load. At the supply 
unit, upon receipt of a new resupply request, this new 
Bequisition is filed, and any older requests for that 
ammunition and that company are destroyed. 
It is important to note that in both a and b above 
*he modelling techniques described give the user the 
flexibility to make the logistics information flow as 
accura+e or inaccurate as desired by controlling the 
randomness of the LON updates. 
4, Assumptions 
The major assumptions made during the resupply 
request process are: 

a. Requests for resupply are an iterative process up the 
chain of command with each level receiving information 
Only rrom its immediate subordinates. 

b. An LON of empty ("7") initiates an immediate request 


for action up the chain of command. 
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c. Formal resupply requests from the company are triggered 
by changes in an ammunition LON. The actual quantities 
of ammunition used to calculate the LON's are available 
at each level of command so that resupply can be 


affected at that level if appropriéte. 


De RESUPPLY 

The resupply process begins with the receipt of a 
resupply request by the Battalion S-4. This receipt 
initiates a sequence of events which ultimately results in 
rounds being placed on the weapon system itself. This 
section explains how resupply of requested ammunition is 
accomplished. The explanation includes modelling the 
Battalion S-4&'s decisicn logic; the resupply logic of the 
company after assets are received from battalion; and the 
distribution decision logic of the platoon leader after a 
resupply is received from the company. The explanations are 
general in nature. A detailed discussion of the logic is 


contained in Appendix A, Section D. 
A battalion's initial reserve of ammunition is 


determined by the number and type of resupply vehicles 


(RSVs) in the support platoon and the type and amount of 
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ammunition thos? vehicles are designated to carry. fThis 
information is determined by the user and entered as input. 
An RSV's hauling capability for an ammunition type is 
determined by its cub2 or weight limitations, whichever is 
reached first. 

Within a battalion, the S-4 is responsible for 
controlling the distribution of battalion reserve ammunition 
assets to subordinate companies. The S-4's responsibilities 
include the following: 

a. Review and prioritization of requests filed by priority 
and time of request. The most critical LONs ("1") are 
filled first. If there is more than one, the requests 
are filled in the order they were received. 

b. Determination of the number of RSV's necessary and 
available for resuppiy missions. 

c. Determination of the proper mix of ammunition types to 
be delivered to a unit in the face of multiple requests 
and limited transportation. 

2. Company Distribution 
Upon the arrival of a resupply convoy, a Company 


Commander takes the following actions: 
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Determines the type and quantity or the ammunition he 
has received. 

Determines the immediate needs of the platoons in the 
company. 

Distributes the ammunition received to each platoon in 
amounts dictated by their immediate urgency of need. 


Re-evaluates the company's levels of need. 


wee Platoon Distribution 





The Platoon Leader's responsibilities for the 


distribution of ammunition resupply to the weapons within 


the platoon are the Same as those of the Company Commander. 


4. Assumptions 


The major assumptions made in developing logic to 


model a battalion's ammunition resupply distribution process 


ares 


a. When a resupply action is triggered at battalion, the 


S-4 responds only to those requests he has knowledge of 
and then only in the amounts listed on that request. 
No further update is permitted until a new request is 


received. 


b. RSVS will not be dispatched from the battalion trains 


With less then a half load of ammunition unless the 


load contains ammunition with an LON of "1", 
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RSV's can carry loads of mixed ammunition but only to 
one company. 

RSV's resupplying the same unit will travel in convoy. 
Tf an RSV is damaged or destroyed all the ammunition it 
is carrying is assumed to be destroyed. The ammunition 
is not replaced during the Simulation run. 

RSV's that complete a resupply mission arrive back at 
the battalion trains with the same load they delivered 
after an appropriate time delay. This Simulates the 
RSV's round trip to an ASP/ATP and permits restocking 
of battalion ammuniton assets. 

Ammunition stockage at the battalion trains is limited 
to the total weight and cube limitations of the 
battalion ammunition trucks earmarked to haul it. 
Individual RSV loads are not "fixed" but rather remain 
Flexible, subject only to the stockage at the trains 
and the weight and cube restrictions of the vehicle 

me Sewer . 

An ATP/ASP has unlimited supplies of all ammunition 
types. The only limiting factor on the amount of 
ammunition an RSV takes back to its battalion trains is 


the vehicle's own weight and cube limitation. 
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fee koDLSTRIBUTION 

In an actual combat Situaticn redistribution of on-hand 
ammunition assets is performed as standard procedure in 
certain situations. This section describes the situations 
which warrant redistribution in this model. It explains 
when and where «he redistributions occur and the maior 
assumptions mad¢ in performing then. 

1. Redistribution Due To Relocation 

Redistribution takes place immediately upon 
completion of any unit move. This activity is accomplished 
within platoons only, with its objective being the even 
redistribution of all on-hand assets. In the model, the 
following actions take place when a move is completed: 
a. All weapons give their respective platoons an 
ammunition update. 
b. Each ammunition type is divided evenly among weapons 
uSing it with respect to the weapon's stowed load. 
2. Redistribution Due To A Firepower Kill 
Redistribution of on-hand assets is performed in the 

event of a vehicle sustaining an F-kill. In this case, the 
platoon redistributes «he ammunition as if it has just 
received a resuoply egual to the ammunition on the F-killed 


Tenmicile. 
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The major assumptions made during a redistribution 


Redistributions only take place at the platoon level. 


A vehicle receiving an F-kill becomes an RSV until all 


oSn-hand ammunition is distributed. 
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A. GENERAL 


This ammunition resupply model represents the first step 
toward the aventual development of a low level, high 
resolution logisitics model designed to interface directly 
with a comparable combat model. Program logic thus far 
developed explicitly depicts current U.S. Army supply 
doctrine at the battalion level. Beginning with the 
individual firer, the model simulates the ammunition 
resupply network responding to identified needs and 
ultimately providing the appropriate ammunition to weapon 
systems. 

In executing this process, the model performs the 
following functions: recognition of shortages at all leveis; 
initiation of requests for resupply appropriate to the level 
of command; determination of quantities to be released to 
fill requests; and delivery of supplies down to the weapon 
systems. The authors have tried to keep the model as 
flexible as possible by designing it in a manner that lets 


the user assign values at input for the critical variables 
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of the resupply process. The remainder of this chapter is 
used <o lay the foundations for continued work based on the 
ideas developed in this thesis. The approach taken in 
Siot-ning the direction of future efforts is whe OeROLEle to 
explicitly highlight some cf the model's major deficiencies; 
to discuss several possible development paths which might be 
taken in expanding the model; and to discuss adjustments 
necessary to integrate this model with a comparabie low 


level, high resolution battalion combat model. 


Eee OODEL DEFICIENCIES 

Fundamental to understanding what a model can do is the 
equally important issue of knowing what a model cannot do. 
This model is deficient in the following areas: 

1. Battlefield Realism - Due to the simplified nature of 
the battle, eee processes are not well played. 
Basic forms of maneuver, elementary command decisions, 
and individual combat action are not modelled beyond 
the simplest levels. These activities have a 
Significant impact on the supply system and represent a 
eeatical d=2ficiency in this model. 

2. Damage Assessment - The Simplified damage assessment 


routine, limited to combat weapon systems only, was 
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developed solely to drive the resupply logic. 
Extension of this damage logic to resupply vehicles, 
development of a maintenance recovery and repair 
capability, and an ability within the supply system to 
respond to item losses would be a significant gain. 
Movement - The model does not depict movement beyond 
she imposition of a simple time delay for travel from 
one section of the battlefield to another. These 
delays are based cn doctrinal distances and do not not 
consider terrain, weather, or suppression. The 
addition of terrain and movement modules would adda 
Significant dimension to the model and permit the 
2xtension of logic into related resupply issues such as 
monte selection, traffic control, and traffic 
congestion. 
Resupply Logic 
a. Tne battalion played in the model is always 
resupplied, after a time delay, with the exact type 
and quantity of ammunition it has released to its 
companies. The source cf this resupply is an 
ATP/ASP that contains unlimited ammunition assets. 


These assumpticns significantly reduce the realisa 
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of the model and should be amended to include, at a 
Minimum, a limit on the resupply available to a 
battalion dictated by the prevailing Command Supply 
Rat2(CSR) and Required Supply Rate(RSR). 

b. Convoys in the model are limited to point to point 
delivery of ammunition. Multiple deliveries by one 
convoy +o several companies is not allowed. fThis 
deficiency decreases the model's realism by limiting 
a battalion's ability to efficiently use its 
transportation assets, and a company's ability to 


control these assets when a convoy arrives. 


fee oan iH OF FUTURE DEVELOPMENT 

Having initiated a basic structure for the resupply 
model, expansion paths for resupply logic, both within tne 
confines of the battalion model itself, and beyond the 
battalion supply point to brigade have become apparent. fThe 
expansion ideas mentioned in this section will be limited to 
those areas of improvement within the supply system itself, 
purposely disregarding 1lssues directed at the model's 
interface with a high resolution combat model. Some of the 
points mentioned in this section have been identified as 


model deficiencies but are re-mentioned here for emphasis. 
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mepansiOn Of this model, with respect to resupply logic, is 


needed in the following areas; 


1. Development of logic to mcre realistically depict the 


transpor+ of ammunition from the ATF/ASP to the 

battalion trains. Such logic should include the 

explicit modelling of supply routes and tne traffic 
control points overseéing these routes. 

The effect of enemy interdiction efforts on the rear 
area supply points. 

Development of a routine to extend the possibility cz 
damage +o resupply vehicles and convoys. 

Development of routines to model naintenance, recovery, 
and repair as well as replacement of damaged systems. 

Extension of delivery logic to allow resupply vehicles 
and convoys the option of delivering to more than one 
company. 

Addition of movement and terrain logic. 

Improvement of the redistribution iogic to include 
provisions for an emergency resupply of ammunition if 
» Serene warrants it. 

Explicit representation of activities at the ATP/ASP to 


include queue and service times for trucks, and 
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ATP/ASP interface procedures. AS méntioned in Chapter 
2, much of this logic has already been modelled in 
Hecker 2k. 

9. The imposition of a Command Supply Rate(CSR) and 
Required Supply Rate(RSR) as a driver for the entire 


resupply process. 


D. INTEGRATION INTO A COMBAT MODEL 

Integration of this model into a low level, high 
resolution combat model presents the following problems: 
the problem of interfacing independently developed progran 
logic; the necessity of developing additional command and 
control logic to blend the two models together; and the need 
to adjust the tactical decision making process to include 
the effects of logistics. Each of these issues is discussed 
separately below. 

The problems of mérging an independently developed 
resupply program into a fully developed combat model were 
recognized and carefully considered in the development of 
this ammunition resupply model. To overcome these problems, 
the model was developed as a self-contained module. The 
foreseeable interface problems with a combat model are thus 


limited to insuring that: the combat model captures 


86 





ammunition expenditures and passes them to the resupply 
logic; the resupply model has movement logic that interfaces 
with the movement logic of the combat model; and the supply 
model's resupply routines interface with the weapon systems 
of the combat model when delivering ammunition. Since the 
model developed in this thesis was specifically designed to 
interface with the STAR model, these changes would be 
limited to: the addition of severai attributes to the chain 
cof command structure; the addition of several attributes to 
the weapon systems; and the integration of convoy movement 
With the STAR movement logic. 

Perhaps the greatest change caused by the addition of a 
resupply module would be its effect on the ccmmand and 
control logic of the combat model. A combat model'ts 
decision process could be expanded to include at least the 
<woO most basic methods of resupply for a battalion, unit and 
cache. Consideration of these two methods would necessitate 
development of logic which could dynamically answer the 
following questions: 

1. Who has priority of resupply? 
2. What ammunition is to be released subject to what 


command restrictions? 
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3. How will resupply be accomplished? Will supply 
personnel be present with any type of equipment? 

4, Where will the resupply be accomplished? At the current 
location? At a subsequent position? At a rendezvous 
Boint? 

Lastly, combat decisions are inevitably influenced by 
the availability or nenavailability of resupply. Inclusion 
of resupply logic into a combat model would force an active 
consideration of resupply issues in making the following 
tactical decisions: 

a. Adjusting rates of fire. 

b. Changing a weapon's primary ammunition of 
engagement. 

c. Decreasing or increasing a weapon's range of 
detection and engagement. 

d. Movement to alternate positions or the withdrawal of 


a unit. 
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APPENDIX A 


A. INTRODUCTION 

This apoendix gives a detailed description of the 
ammuniticn resupply model in a format suitable for use by 
programmers and analysts. The discussion in this appendix 
approaches the model from a broad perspective in order to 
Show the effect of the techniques used to model the "real 
world" resupply process. Prior to discussing the 
feremoaology itself, a brief description of the SIMSCRIPT 
IZ.5 programming language used in the model is provided for 
readers unfamiliar with the language. A detailed 
explanation of the actual code developed is provided in 


Appendix B. 


feet OF SIMSCRIPT I1.5 IN THE SODEL 

The SIMSCRIPT II.5 programming language is designed to 
model discrete-event simulations. It is a user friendly 
language with a structure very similar to everyday speech. 
This feature enables a reader tc quickly grasp and follow 


the flow of any program. Beyond the narrative clarity, 
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SIMSCRIPT provides an organizational structure which extends 
a programmers conceptual horizon beyond the normal bounds 
imposed by the use of variables and arrays. Central to this 
structure are the key ideas of entities, attributes, and 


Sets. 


tJ 
}+- 


ncities are program elements whose characteristics are 
being modelled in the simulation. In the ammunition 
resupply model for example, tanks, platoon leaders, company 
commanders and supply officers are classes of entities in 
#he system. Attributes are discriptors which depict the 
entity's characteristics. In the model, every platoon 
lead2r entity carries attributes which define his unigue 
company command=r. Thus, aithough all entities in the sane 
class have the same attribute names, they can be 
distinguished from seach other by the values of their 
attributes. Attributes may have real, integer, or 
alphanumeric values. 

A set is a collection of entities possessing some common 
property. Tne ammunition resupply model uses sets to track 
the type and amount of ammunition on-hand in each platcon. 
This is done by creating an entity for each type of 


ammunition with attributes which record the quantity 
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memes ed and actttally on-hand. Each entity is then filed in 
a platoon's ammunition set and its attributes thereaiter 
meack Only that platoon's ammunition status. 

An event in SIMSCRIPT is an occurrence which takes place 
at a specific simulated time. Events can change the values 
of entity attributes, remove or add entities to sets, create 
or destroy entities, or schedule other events to take place 
at later times. In the model, a weapon which expends all of 
its ammunition keys an event which notifies the platoon 
leader and starts decision logic for resupply. Events take 
place instantaneously and do not conSume Simulated time. 

The use of SIMSCRIPT II.5 greatly simplifies the 
tracking of ammunition expenditures throughout the chain of 
command. The actual set, entity, and attribute structure 


used in this model is explained in detail in Appendix B. 


C. GENERAL MODEL METHODOLOGY 

The ammunition resupply model developed fcr this thesis 
is a stochastic discrete-event simulation designed to 
portray ammunition resupply procedures within a U.S. combat 
battalion. The model is a stand-alone, closed loop process 
which simulates the following activities within a combat 


Dattalion: periodic updating of individual weapon and unit 
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mmmunaitlon status; recognition of tae need for and 
submission of requests for resupply; and receipt and issues 
Sevsurplies from battalion reserve stocks. he overall 


process modelled is depicted in Pigure 2 below. 
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Figure 2; Resupply Process 


The fundamental process depicted in the figure is duplicated 
at all levels of command (weapon, platoon, company, and 
battalion), differing only in the responsé options available 


at each leval. 


Pee SUT REQUIREMENTS AND THE INITIALIZATION OF DATA ARRAYS 
Input to the model is used to accouaplish the following: 
she creation of entities played in the simulation; the 


establishment of chain of command relationships between 
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entities; the scheduling of initial ammunition update times; 
and the establishment cf parameter vaiues for supply action 
and r2sponse(LON Thresholds). This initialization process 
is controlled by routine BLU.CREATE, which creates the major 
mmr es Dlayed and calls, in turn, routine BASIC.LOAD to 
establish initial ammunition loads, and routine PARAMETERS 
to initialize the critical data arrays and global variables. 
enerating Resupply Reguirements - The Battle 
Generation of requirements to exercise the 
ammunition resupply model was initially to have been 
accomplished through interaction with the low level, high 
resolution STAR combat model. However, attempts to utilize 
Moe STAR battle in its current configuration led to 
difficulties with the pace of battle problem previously 
discussed in Chapter 1 and the objective was abandonned, at 
least for this thesis effort. In lieu of this, a simplified 
battle was developed strictly to generate requirements for 
the model. It must be emphasized that significant 
conclusions cannot be drawn from the battle summaries 
produced by this model. The sole function of the battle 
designed is to generate requirements in order to exercise 


the model's resupply logic. The requirements generated for 
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*he model can be grouped into three broad catagories: 
ammunition expenditures, damage and destruction of combat 
yehicles, and unit movement. The following paragraphs 
explain how the information generated is used in the model. 
as Ammunition Expenditures 
Ammunition expenditures take place only during 
scheduled battle periods. These periods are randomly 
scheduled for six hours a day by the event BAT.L.TIME. 
Assessmert of the quantities of ammunition fired by each 
weapon is determined in routine BATTLE which is called by 
e¢ach weapon system when it updates its ammunition status. In 
execution, routine BATTLE performs the following functions: 
(1) Checks if a battle is in progress ~ This is simply a 
check if the Simulation tine, TIME.V, is greater than 
the battle starting time, B.START, and less than the 
Baetle*s end time, BeEND. If it is outside this linit, 
there is no active on-going battle and the routine 
returns without action. 
(2) Determines if a weapon fires - A check is made on each 
of six possible weapons carried by a weapon system to 
see if they have fired. This is accomplished by 


comparing successive random number draws against a 
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(3) 


probability of firing for each ammunition owned by the 
weapon system. If the random number drawn is less 
shan the assigned probability of fire, the ammunition 
being tested has fired, and expenditures are computed. 
If not, no expenditures are computed and the logic 
transfers to the next ammunition carried on the weapon 
system. 

Expends Ammunition - Each of the six ammunition types 
carried by a weapon system is assigned a unique rate 
Smeeore. This pate of fire is stored in an array, 
ROF, which is input in routine PARAMETERS. If the 
determination is made that an ammunition has been 
fired, the quantity expended is computed through the 
use of an exponential function. Lambda for the 
function is set equal to the ammunition rate of fire 
and the exponent is completed by multiplying this 
lambda times the elapsed battle time. This technique 
inevitably causes a greater expenditure of rounds as 
the battle time increases, however, its overall effect 


On the running cf the model is negligible. 
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b. VehicleyWeapon Damage and Destruction 

Logic depicting the damage and destruction of 
vehicles and weapons was added in order to exercise the 
model's capability to adjust for ammunition assets lost 
throughout the battle. Losses and damage are generated only 
for combat weapon systems. Supply systems are not subject 
to combat loss or damage. 

The modelling of vehicle/weapon damage and 
destruction is done in routine BATTLE with assessment of 
loss or damage limited to the 6 hour battle period. There 
Meemeour types of damage played, M-kill, F-kill, M/F-kill, 
and K-kill. Probabilities for each type of damage are 
weapon system unique and obtained from an array, 
POD(Probability of Damage), input in routine PARAMETERS. 
Assessment of damage is accomplished by drawing a separate 
random number against each probable type of damage. If the 
number drawn is less than the probability for the type of 
damage being reviewed, the weapon sustains the damage. This 
technique ieaves open the possibility that a weapon may 
Sustain multiple types of damage, however, this side-effect 


is of little importance to the model's execution. 
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c. Unit Moves 
The possibility of a company relocating during 
+he simulation was incorporated in order to exercise 
redistribution logic contained in the supply model. The 
assumption underlying the need for the inclusion of this 
Meqae is that tactical units will seek to redistribute 
ammunition either before or after displacement in order to 
achieve an ammunition balance among its weapon systems. The 
execution of a unit move within this model in no way affects 
the conduct of the remainder of the battle. Unit moves are 
scheduled randomly in event BAT.L.TIME at the start of each 
6 hour battle. Redistribution of company assets is 
accomplished upon completion of a move within each of the 
company's platcons. Cross-leveling of ammunition between 
platoons is not modelled. In execution, each company draws 
auniform (0,1) random number, and, if that number is less 
than a user désignated probability of move, the company will 
move at the end of the baxtle. 
2. Determining the Level of Need (LON) 

The determination of Level of Need is performed 

independently and at random intervals for every weapon 


System, platoon, and company played in the simulation. The 
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Maepose of ah LON is te provide an indication of the urgency 
of need an slement has for each of the ammunition types it 
possesses. A distinct LON value is computed at each level 
of command. This mnodels the increasingly wider perspective 
of the battle taken by commanders further up the chain of 
command. The net effect of this technigue is to limit the 
importance of any one ammunition type as it is factored 
against other ammunitions played. The following subsections 
fully discuss the details cf the process just described. 

a. Imperfect Information 

As discussed in Section C, Chapter 3, 

information in a logistics network iS approximate at best. 
In the mod2l, this imperfection is achieved by randomizing 
the times at which ammunition updates occur at each level 
and by limiting the knowledge passed from cne level to 
another to that obtained in the most recent update. The 
following example illustrates the effect of this technique. 
A tank updates its ammunition status 10 minutes into the 
battle and finds 40 HE rounds on-board. At 30 minutes into 
MeesDa-tle the tank has 30 rounds remaining. At this point, 
*he platoon leader conducts an update and is informed that 


the tank has 40 rounds on-board. The platoon leader then 
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bases his decisions on this imperfection information. 
Similar update processes are performed at each level of 
command with the information provided forming the basis of 
LON computations at that level. The degree of imperfection 
in the information passed depends on the length of time 
between updates. These time intervals are entered by the 
user as input in routine PARAMETRS. 
b. Initial Assets and Capacities 

The initial ammunition assets cf é¢ach weapon and 
resupply vehicle are input by the user in routine BLU.CREATE 
as the temporary attributes OH1 through OH6. The number of 
ammunition types that can be played in the model is 
unlimited; however, the quantity of each ammunition type on 
board a weapon system is limited to a maximum stowed load 
figure. Maximum values are set for each ammunition type and 
carried as the attributes, SLOAD1 through SLOAD6, on every 
weapon system. The stowed load configuration on a weapon 
system represents the users assessment both of what should 
be and what can be carried on a weapon system. This 
configuration is unique to each combat weapon system entity. 

The platoon and company equivalent of a stowed 


load for an ammunition type is called the base load for an 
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ammunition type. Base loads for an ammunition type are 
computed by Summing over the stowed loads carried on all 
undamaged elements within a unit. 

c. Weapon LON's 

Weapon systems form the basis for all LON 
calculations in the model Since it is at the weapon level 
that ammunition is expended. Levels of need for a weapon 
system are computed in routine W.AMMO for each of the six 
possible ammunition types a weapon system might possess. 
Routine W.AMMO calls routine BATTLE to generate ammunition 
expenditures, and based on these expenditures, W.AMMO 
updates a systems Knowledge of lts current ammunition 
status. W.AMMO is called from severai events for different 
purposes. 

Event UP.W.AMMO calls routine W.AMMO randomly 
throughout the simulation in order to model a weapon 
System's crew periodically checking its on-hand resources. 
UP.W.AMMO is scheduled individually for each weapon systen 
played based on successive draws from a uniforn 
Seectrroution. The delimiting times for the distribution, 


WMIN and WMAX, are input by the user in routine PARAMETERS. 
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The event is repaatedly re-scheduled throughout the 
Simulation unless the weapon updating sustains some battle 
damage. 

Events CO.RESUPPLY.ARR, REDISTRIBUTE, and 
FIREKILL call routine W.AMMO for all undamaged weapon 
systems within a unit in order to obtain an immediate update 
of the current situation prior to executing their respective 
program segments. These calls simulate a weapon system's 
crew checking its on-hand resources prior to any resupply 
econ. 

fhe actual calculation of an LON for an 
ammunition type is accomplished by taking the on-hand 
ammuniztion of an undamaged weapon and dividing it by <he 
authorized stowed load of that ammunition for that weapon. 
The resulting percentage is compared to the weapon Systen 
threshold values stored in the array WPNLON which is 
initially input in routine PARAMETERS. The threshold values 
contained in the array mark the lower boundaries of LON 
Catagories. Figure 3 is an example of an LON calculation 


for APDS ammuni*ion on board a tank. 
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System type - Tank 


Wpn type - M1 % = on-hand / stowed load 
Ammo type - APDS = 20 / 40 
On-hand - 20 rounds = .5 


Stowed Load - 40 rounds 


Se ia2 85 
A eas 
Se 6 AO 
swe as Loe 
eee 2 050 


Mrorefore since .60 2 .50 2 .4O0 
WPLON = "3" 
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Figure 3: Weapon LON Example 


d. Platoon LON 


Platoon LON information is updated in the 
moutone P.CLASS.V. The process performed in this routine is 


essentially a summation of the information carried on-board 


“he undamaged weapons in the platoon. This process updates 
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both «he platoon's current on-hand information, and the base 
load information for that ammo type. As each ammunition is 
updated, a platoon percent fill is calculated for each 
ammunition *«ype by dividing the current on-hand quantity of 
an ammunition by its current base load in that platoon. The 
percent fill calculated is compared to the platoon LON 
threshold values for that ammunition type. These criticai 
values are stored in the array PLTLON which is input in the 
routine PARAMETERS. The threshold values contained in the 
array mark the lower boundaries of the lon categories. 
P.CLASS.V is called by several events for different 
purposes. 

Event UP.PLT.AMMO cails routine P.CLASS.V 
randomly throughout the simulation in order to model a 
platoon lead*r periodically checking the platoon's on-hand 
resources. UP.PLT.AMMO is scnoeduled individually for each 
weapon system played based on successive draws from a 
uniform distribution. The delimiting times for the 
distribution, PMIN and PMAX, are input by the user in 
routine PARAMETERS. The event is repeatedly re-scheduled 
throughout the simulation unless all weapons in the platcor 


Sustain damage and can no longer use ammunition. 
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Pvc omeOCenReoUreE LY .Arh, REDISTRIBUTE, and 
meee keLt call routine P.CLASS.V for all platoons within a 
unit in order to obtain an immediate update of the current 
situation prior to executing WE eng yee progran 
segments. These calls simulate a platoon leader checking 
the unit's resources prior to any resupply action. 

Figure 4 is an example of how a platoon LON is 
calculated. It is important to note in the example that the 
stowed load and on-hand ammunition of the 3rd tank 1s not 
considered because the tank is an M-kiil. Also, the stowed 
load of tank 2 is disregarded because the weapon can no 
longer fire since it has been F-killed. The on-hand 
ammunition of tank 2 is not dropped from the computation 
however, due to the fact that the tank is still mobile and 
can be used as a resupply vehicle to deliver ammunition to 
other systems in the platcon. 

@. Company LON 

Company LON values are computed and assigned in 
routine COM.AMMO. In evaluation of this LON, the first step 
performed is to sum over all assigned platoons in order to 


update the company's on-hand and base load information. 
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SYSTEM _WPN ___AMMO___STOWED LOAD ___ON-HAND___ STATUS 
(1) Tank M1 AP 40Q rounds 20 rounds Alive 
() Tank M1 AP 40 rounds 15 rounds F-kill 
(3) Tank M1 AP 4Q rounds 30 rounds M-kill 
(4) Tank M1 AP 4Q rounds 25 rounds Alive 


LT_ LON THRESHOLDS (APDS) 
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ee ee 
% = Tot Plt on-nand ammo(AP) / Sum Wpn stowed loads (AP) 


60 / 80 = .75 


Prerefor2 since .90 2 .75 2 .65 
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Figure 4; Platoon LON Example 


A percent fill value is then computed by dividing the 
on-hand guantity for sach ammunition by the required base 
load for that ammunition. This percent fill is then compared 


£0 company LON threshold values stored in the WPNLON array 
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which is input initially in the routine PARAMETERS. The 
+hreshold values contained in this array mark the lower 
boundaries of the LON values. COM.AHMO is called by several 
events for different purposes. 

Event UP.COM.AMMO calls routine COM. AMMO 
tandomly throughout the simulation in order to model a 
company commander periodically checking the platoon's 
on-hand resources. UP.COM.AMMO is scheduled individually 
for each weapon system played based on successive draws from 
a uniform distribution. The delimiting times for the 
distribution, CMIN and CMAX, are input by the user in 
roux~ine PARAMETERS. The event is repeatedly re-scheduled 
throughout «he simulation unless all weapons in the company 
Sustain damage and can no longér use the ammunition. 

Events CO.RESUPPLY.ARR, REDISTRIBUTE, and 
FIREKILL call routine COM.AMMO for the company receiving 
resupply in order to obtain an immediate update of the 
current situation prior to executing their respective 
program segments. These calis Simulate a company commander 
checking the unit's resources prior to any resupply action. 

Figure 5 gives an example of how a company LON 


is calculated for APDS ammunition. .In this example the 
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first platoon data is taken from the platoon LON exanple 
given in Figure 4. The company example depicts 2nd platoon 
having 4 M1 *+anks, each tank with a stowed load of 4O AP 


rounds and total platoon cn-hand assets of 80 AP rounds. 


———_ 
PLT SYSTEM WEN AMMO STOWED LOAD ON-HAND 
tank M1 AP 80 60 
tank M1 AP 160 80 
tank M1 AP 80 20 


COMPANY LON THRESHOLDS (AP) 


usu > 85 
nyt > .60 
m3 > .40 
mau > . 20 
Hq" > 0.0 


Percent = Tot Co. on-hand Ammo / Sum of Plt stowed loads 
= 160 / 320 
= 5 


Therefore since .60 2 .50 2> .40 


COMLON ut 
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Figure 5: Company LON Example 
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In a similar manner it can be seen that the 3rd platoon has 
2 M1 tanks remaining with 20 AP rounds between them anda 
stowed load of 80 rounds, 20 per tank. 
3. Reguests for Resupply 
Resupply requests are made by a company and sent to 
the battalion's S-4 based on the information passed up the 
chain of command from the individual weapon systems through 


the subordinate platoons. Within the model logic, the 


periodic updating of LON information up to company level is 


vt 


he key to transmission of these resupply needs. Beyond the 
company level a reguisiticn processing system replaces the 
LON concept. Prior to the submission of a "formal" 
requisition by the company to the S-4, several informal 
actions that take place which key the submission of a 
requisition for a particular ammunition type. These actions 
occur at the weapon, platoon, and company levels. This 
section explains this informal process which resuits in the 
Battalion S-4 receiving a valid zequisitiorn from the 
company. 
a. Weapon Systems 

Weapon systems do not request ammunition 


resupply; they simply pass their most current knowledge to 
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the platoon at the time a platoon check is made. [In the 
event «hat a weapon system exhausts its supply of an 
ammunition type, an immediate scheduling of the event 
UP.PLT.AMMO is made. This logic Simulates a weapon system 
snforming its platoon leader of the situation, and the 
platoon leader, in turn, performing a quick check of the 
rest of the platoon to see how extensive the problem is. 
b. Piatoon 

Platoons do not request resupply; they 
periodically check all subordinate systems and pass on 
information for each ammunition type to the company when the 
company checks on itS ammunition status. In the event that 
a platoon exhausts its supply of an ammunition type, an 
immediate scheduling of the event UP.COM.AMMO is made. This 
logic simulates a platoon leader informing the unit's 
company commander of the situation, and the company 
commander, in turn, performing a quick check of the rest of 
the company to sée how extensive the problem is. 

Gc. Company 

The company is the first level of command 

permitted to create and submit resupply requisitions in 


order to correct deficiencies in a unit's ammunition 
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posture. Within routine CO.AMMO, changes in the Level of 
Need computed for an ammunition type trigger the creation of 
a resupply request, RES.REQ, for that specific ammunition 
type. These requests are transmitted to battalion supply by 
scheduling the event UP.S4Y.AMMO and passing the company's 
requisition list aS an argument to battalion. The scheduled 
time of arrival for the reguest is determined by drawing a 
random number from a unifcrm distribution. The delimiting 
times for use in the distribution, MINTRIP and MAXTRIP, are 
input in routine PARAMETERS. Use of this distribution to 
schedule the event time models the deiay caused by *¢he 
necessity to physically carry the requests to the supply 
point. 
d. Battalion 

Por the purposes of this model, a battalion does 
not submit requests for resupply. Convoys returning from a 
company resupply mission are assumed to have been reloaded 
at the ASP/ATP with exactly the same quantity of ammunition 
they had just delivered to a company. In this way, 


battalion stocks are constantly refilled. 
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Storage and issue of a battalion's reserve 

ammunition is simulated in event UP.S4.AMMO. The purpose of 
UP.S4. AMMO is to model the actions of a battalion S-4 
officer allocating his limited ammunition and transportation 
assets in response to requests from the supported units. 
The event is scheduled in routine COM.AMMO when a resupply 
request is created. Punctionally, the routine accompiishes 
these actions through evaluation of the follcwing 
considerations: the availability of supply and 
transportation assets; the need to maximize the use of 
Shipping space cn board resupply vehicies; the need to 
adjust shipments in the face of priority requests; and 
control of the dispatch of resupply convoys. The 
Subsections which follow discuss each of these 
considerations. Significantly, in the program logic as it 
exists, resupply conveys are iimited to one stop deliveries. 
Multiple unit deliveries are not permitted. 

a. Availability of Supply and Transportation Assets 

Stock acccuntability of ammunition is maintained 
for each CLASS V({ammunition) item belonging to a supply 


officer in a temporary enttiy SCL.V.ITEM. Resupply requests 
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to the S-4 are matched against the on-hand balance in this 
temporary entity to determine if the supplies are available 
for release. A concurrent determination of the availability 
of transportation assets is made through a comparison of the 
total weight and cube available on resupply vehicles for 
Shipping and the total weight and cube requested. 
be. Maximization of Shipping Space 

Program logic allows more than one tyre of 
ammunition to be loaded on a Single truck. This models the 
S-4 seeking to effectively utilize the limited resources at 
his disposal. The identity of ammunition stocks released to 
fill a request is modelled through the creation of a 
temporary entity, T.CGO. This level of detaii permits a 
determination of the total cargo manifest loaded on any 
individual truck. 

c. Adjustments Due to Priority Requisitions 

A key assumption modelled in the program is that 
a unit commander will order the quantity of supplies 
necessary to refill the unit's base load for an ammunition 
type. As such, in the face of multiple priority 1 and 
priority 2 requisitions and limited transportation assets, 


program logic models an S-4 decision to reduce fill on 
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individual requisitions in order to permit a greater number 
of requisitions to be filled. This reduction in fill is 
flexible subject only to the maximum lower bounds C.L1.PCT 
(CRITICAL LON 1 PERCENT) and C.L2.PCT(CRITICAL LON 2 


PERCENT). These deliniters are input in routine PARAMETERS. 


Ee. RESUPPLY ACTIVITIES - RECEIPT OF SUPPLIES 

The transport of supplies to fill requisitions basically 
follows the reverse path of the requisition flow. This is to 
say that supplies are issued through the chain of command 
back to the weapon systems. At each level of command, new 
decisions are made as to the apportionment of the supplies 
to subordinate levels based on the most current information 
available. In executing the applicable routines modelling 
this process the first step performed is an update of the 
ammunition status of all levels. The apportionment process 
itself involves the repetitive computation at each level of 
a ratio (subordinate need / total unit need) times the 
gGuantity delivered. The pattern for this process is set in 
event CO.RESUPPLY.ARRIVE. This event is scheduled to mark 
the arrival of a resupply convoy at a company unit. 
Additionally, two other instances involving a similar 


reapportionment of ammunition were included in the model. 
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These are FIREKILL and REDISTRIBUTE. Event FIREILL nodelis 
a platoon leader's decision to distribute the ammunition 
assets from non-functional weapon Systems to the remainder 
of the platoon. Event REDISTRIBUTE models an assumed 
standard operating procedure that requires platoons to 
cross-level ammunition assets between weapons after a unit 
move is executed. This routine differs from the two previous 
in that the basis for distribution of the assets is the 
ratio of the weapon system's stowed load to the platoon's 


base load times the total quantity required for the platoon. 





This appendix provides a detailed explanation of the 
code developed for the ammunition resupply model. For this 
discussion, «he model has been broken out inte its major 
routines and events with each being discussed separately. 
The PREAMBLE section contains a detailed definition of every 
entity, attribute, set, and global variable used in the 
program. Thereafter, discussion of routines and events 
includes: an abbreviated glossary of terms, a listing of the 
program cods, and a line by line description of the code. 
All definitions within a section are grouped by their 
SIMSCRIPT category then listed alphabetically. If an 
abbreviation is unclear an unabbreviated name is given in 


parentheses beside it. 


fee ERS AMBLE" 

The preamble provides the compiler with definitions 
regarding: entities, attributes, and sets; events and 
routines; global variables and arrays. Many of the 


descriptors used in this preamble are taken directly forn 
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the current STAR model. Those taken directly from STAR are 


redefined here for clarity purposes and can be idéntified by 


an asterisk(™). 


1. Routines 


The routines of this model are described in detail 


in sections C through N of this appendix. 


are as follows: 


BLU. CREATE 
BASIC.LOAD 
Pe CLAD. ¥ 
BATTLE 
FILE.UP.DATE 
WT .AND. CUBE 


2. Events 


The routines used 


PARAMETERS 

W. AMMO 

COM. AMMO 

UP. DATE 
LOAD.THE.TRUCKS 
PRI. RESUPPLY 


The events for this model are explained in detail in 


sections N through Z of this appendix. The events of the 


model are: 


je UBS/ 5 180.5 ska) 

UR ERG 
CO.RESUPPLY.AR 
UP.S&.AMMO 
STOP.SIMULATION 
UP.PLT. AMMO 


BAT.L.TIME 
BN.ARRIVE 
MOVE 
REDISTRIBUTE 
UP.COM. AMMO 
UP.W. AMMO 
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permanent, meaning they remain active throughout the 

program's execution, cr temporary, meaning they can be 

created or destroyed during program execution. Definitions 
of both type of entities are listed below. 
Permanent Entities 

COMPANY.COMMANDER (**). Used to model the company commander's 
thought process. Owns sets containing the unit's 
platoons (CO.UNIT composed of PLATOON.LEADERS) and the 
unit's unigue ammunition listing (CO.AMMO composed of 
CCL.V.ITEMS). 

PLATOON. LEADER (*). Used to model the platoon ieader's 
thought process. Owns sets containing the unit's weapon 
systems(PLAT.UNIT composed of TANKS) and the unit's 
ammunition listing (PLT.AMMO composed of PCL.V.ITEMS). 

MeerGY. OFFICER. Used tc model a battalion supply officer's 
thought process. Owns the following sets: 

S.AMMO (SUPPLY AMMUNITION). Contains the various 
ammunition types (SCL.V.ITEMS) which each supply 


SEricer Must stock. 
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SeUNeraSUPP LY UNET). Contains the unit's supply 
vehicles (TANKs). 

SANT. Lest (SUPPLY @WANT LIST). Comtains the unit's 
outstanding requisitions (RES.REQ) that must be 
foiled. 

SCONVOY (SUPFLY CONVOY). Set cf ELEMENTS which make up a 
COnvioly. EUENENTS, in turn, is composed of a set of 
supply vehicles(TANKS) designated for a supply 


mission. 


eG... LTEM (COMPANY CLASS V ITEM). Holds information for a 
company about a particular ammo type owned by the unit. 
Belongs to the set C.AMMO. 

CONVOY. Holds information as to the type and amount of 
Supplies being sent to a particular unit. Owns ELEMENTS 
which make up a convoy. ELEMENTS, in turn, owns the 
trucks (TANKS) that have been designated to carry the 
supplies. 

Peuevs LEN {PLATOON CLASS V ITEM). Holds information for a 
platcon about a particular ammo type used by the unit. 


Belongs to the set PLT.AMMO. 
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PEs. REQ (RESUPPLY.REQUISITION). Models a presert day 
requisition form. Provides information between users 
and the supply system. A RES.REQ is used to hold 
requirements information for a variety of purposes 
*hrough its membership in various sets. These are: 
SewANT.LIST. Company information owned by a 
COMPANY.COMMANDER. 

SWANT. LIST. Supply information owned by a 
SUPPEY~OFFICER. 

C.CGO.LIST. Convoy cargo list owned by a CONVOY. 

Seve LL EM (SUPPLY CLASS V ITEM). Holds information for a 
supply unit about a particular ammo type used by the 
unit. Belongs to the set S.AMMO. 

T.CGO(TRUCK CARGO). Holds information concerning the 
Supplies loaded on a truck. Belongs to the set CARGO. 

TANK(*). Represents any vehicle or weapon system on the 
battlefield. Used to distinguish individual vehicles as 
to type and functicn. Tanks belong to several 
distinguishing sets: 

INK. ALIVE (TANK ALIVE) (*). Owned by the system this set 
keeps track of the alive/dead status of individual 


TANKs. 
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PLAT.UNIT(PLATOON UNIT). Combat systems and vehicles 
belong. Owned by a PLATOON. LEADER. 

S.UNIT(SUPPLY UNIT). Supply vehicles only belong to this 
set which is owned by a SUPPLY.OFFICER. 

M.ELEMENTS. Specifies membership in a CONVOY. 

4. Atsribures 


Permanent Attributes (INTEGER) 
meen. Ve. LLEMS (NUNBER CF COMPANY CLASS V ITEMS). 
COMPANY.COMMANDER attribute specifying the number of 
ammunition types(CCL.V.ITEMS) used by the company. 
feck. V.ITENS (NUMBER OF PLATOON CLASS V ITEMS). 
PLATOON. LEADER attribute specifying the number of 
ammunition types (FCL.V.ITEMS) used by ths platoon. 
feoeu. VY. LTEMS (NUMBER OF SUPPLY CLASS V ITEMS). 
SUPPLY.OFFICER attribute specifying the number of 
ammunition types (SCL.V.ITEMS) used by the battalion 
supply officer. 
PCO.CDR (PLATOON COMPANY COMMANDER). Specifies a platoon's 
commander. 
REQN (REQUISITION). Attribute of a COMPANY.COMMANDER 
Specifying the total number of resupply requests filed 


by a commander. 
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SCO.CDR (SUPPLY COMPANY COMMANDER). Specifies a supply unit's 
commander. 


S4U.OFF (S& OFFICER). Attribute of a COMPANY. COUMANDER 


specifying the unit's supply officer. 


STATUS. Attribute of a RES.REQ indicating where the request 
currently is. Its possible values are: TOS4, TOCO, and 
TOATP. 

CNOMEN (COMPANY NOMENCLATURE). Attribute of a CCL.V.ITEM 
containing the nomemclature of a particular ammo. 

PNOMEN (PLATOON NOMENCLATURE). 

RNOMEN (RESUPPLY NOMENCLATURE). Attribute of a RES.REQ 
specifying the reguested ammo's nomenclature. 

SNOMEN (SUPPPLY NOMENCLATURE). Attribute of a SCL.V.ITEM 
specifying the requested ammo's nomenclature. 

TNOMEN (T.CGO NOMENCLATURE). Attribute of T.CGO containing 
the name of the ammunition item carried. 

Temporary _Attriputes (INTEGER) 

AMMO1(*) (AMMUNITION 1). This variable is used as a shortened 
form for AP.TOW ammunition. 

AMMO2(*) (AMMUNITION 2). This variable is used as a shortened 


form for HE.DRAG ammunition. 
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AMMO3 (*) (AMMUNITION 3). This variable is used as a shortened 
Form £Or AWT.OR.MNSL3S ammo. 

AMMO4 (*) (AMMUNITION 4). This variable is used as a shortened 
form for AW2.OR.ADM ammo. 

AMMO5 (*) (AMMUNITION 5). Actual on-hand balance of the fifth 
ammo type fired by a TANK. 

AMMO6 (*) (AMMUNITION 6). Actual on-hand balance of the sixth 
ammo type fired by a TANK. 

AP. TOW (*) (ARMOR PIERCING/TOW) Actual on-hand balance of the 
first ammo type fired by a TANK. 

TAC(TANK AMMUNITION CODE). Supply code which points to 4 
specific ammunition fired by a TANK. Six are specified 
on a TANK: 

TAC1(TANK AMMUNITION CODE 1). Contains the code value 
for the first ammo type fired by a TANK. 

TAC2 (TANK AMMUNITION CODE 2). Contains the code value 
for the second ammo type fired by a TANK. 

TAC3 (TANK AMMUNITION CODE 3). Contains the code value 
for the third ammo fired by a TANK. 

TACY (TANK AMMUNITION CODE 4). Contains the code vaiue 


for the fourth ammo fired by a TANK. 


122 





TACS (TANK AMMUNITION CODE 5). Contains the code value 
for the fifth ammo fired by a TANK. 

TACS (TANK AMMUNITION CODE 6). Contains the code value 
for the sixth ammo fired by a TANK. 

AW1.OR.MSL3(*) (ALTER WEAPON? OR MISSILE3 AMMUNITION). Actual 
on-hand balance for the third ammo fired by a TANK. 

AW2.OR.ADM (*) (ALTER WEAPON2 OR AIR DEF MISSILE). Actual 
on-hand balance for the fourth ammo fired by a TANK. 

mmemor.LOSS(COMPANY COMBAT LOSS). Attribute of a CCL.V.ITEM 
indicating whether the need for an ammo type is still 
viable. 

C.MV.STATE (CONVOY MOVEMENT STATE). Indicates if a convoy has 
Meet its start point. Equals "0" at the start point and 
a’ :f departed. 

C.NUM.REQ(COMPANY NUOMBER OF REQUESTS). Attribute of a 
CCL.V.ITEM containing the total number of requests made 
for that ammo type. 

C.RND.CNTR (COMPANY ROUND COUNTER). Argument for the event 
UP.COM.AMMO, points to the weapon system it is updating. 

Monon? (COMPANY SHORTAGE). Attribute of a CCL.V.ITEM holding 


the number of rounds the company is short for that round 


type. 
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mei COMPANY AMMUNITION CODE). Attribute of a CCL.V.ITEM 
which points to a specific ammo type fired by the 
company weapon systems. 

CAMMO.LON(COMPANY AMMUNITION LEVEL OF NEED). Attribute of a 
CCL.V.ITEM indexing the company's overall need for an 
ammo *ype. 

CCURR. LOAD (COMPANY CURRENT LOAD). Attribute of a CCL.V.ITEM 
holding the company commander's knowledge of the on-hand 
balance for rounds of a particular type. 

CO.B.LOAD(COMPANY BASE LOAD). Attribute of a CCL.V.ITEM 
holding the total number of rounds the company needs to 
be at optimal fill. 

CO.CNVY (COMPANY CONVOY). Argument of event CO.RESUPPLY.ARR 
(COMPANY RESUPPLY ARRIVE) pointing to the CONVOY 
ae civing. 

COCDR(COMPANY COMMANDER). Attribute of a TANK pointing to 
its COMPANY.COMMANDER. 

COLOR (*). Attribute of TANK indicating the TANK's force 
membership. 


MON indicates RED FORCE 
"7" andicates BLUE FORCE 
CONTRKS (CONVOY TRUCKS). Attribute of a CONVOY specifying the 


number of vehicles in a particular convoy. 
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CPNTR (CONVOY POINTER). Attribute of a T.CGO pointing to the 
convoy «he cargo is leaded on. 

CRESUPPLY.REQ (COMPANY RESUPPLY REQUEST). Attribute of a 
CCL.V.ITEM indicating whether a RES.REQ has been 
Submitted previously. 

@UePKS (CUBE PACKAGE). Attribute of a SCL.V.ITEW specifying 
the cube of an ammunition pallet. 

DEMAND. Attribute of a SCL.V.ITEM holding tne total demand 
for an ammo type. 

more (DISTRIBUTOR). Argument for event REDISTRIBUTE pointing 

\ to the unit's PLATOON.LEADER 

FPKILL(FIREPOWER KILL) (*). Indicates whether a TANK has 


sustained a firepower kill during the battle. 


"Oo" andicates no 
"7" indicates yes 
MARCH.ORDER. Argument for the event MOVE holding the poin 


ct 
(iD 
as | 


of the company receiving orders to move. 

HE.DRAG(HIGH EXPLOSIVE/DRAGON AMMUNITION) (#) . Actual on-haud 
balance of the second ammo type fired by a TANK. 

ISSUER. Argument of event UP.S4.AMMO pointing to the S-4 
currently updating. 

ISSUBE. Argument of event UP.S4Y.AMMO pointing to the company 


initiating the request for resupply. 
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KKILL(CATASTROPHIC KILL) (#). Indicates whether a TANK has 
sustained a catastrophic kill during the battle. 


"go" indicates no 
"7" sandicates yes 
MenareST. Attribute of a RES.REQ pointing to the CONVOY 


supplies are loaded on. 
MAX.CUBE. Attribute of a TANK indicating its max cargo cube. 
MAX.WT. Attribute or a TANK indicating its max cargo weight. 
MFKILL(MOBILITY/FIREPOWER KILL) (*). Indicates whether a TANK 
has sustained mobility and firepower damage. 


"Oo" indicates no 
"1" indicates yes 
MKILL(MOBILITY KILL) (#). Indicates whether a TANK has 


Sustained mobility damage. 


"QO" andicates no 
"1" indicates yes 
Peewee LLOC(NUMBER OF TRUCKS ALLOCATED). Attribute of a 


feo. REQ indicating the total Number of trucks allocated 
moemmOvVe a RES.REQ. 
NAME (*). Indicates the number of a TANK in the battle. 
menos Attribute of a SCL.V.ITEM holding the balance 
on-hand of stocks for an ammo type. 
OH1(ON-HAND 1). Current balance of ammunition 1 on a TANK. 
OH2 (ON-HAND 2). Current balance cf ammunition 2 ona TANK. 


OH3(ON-HAND 3). Current balance of ammunition 3 on a TANK. 
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OH4 (ON-HAND 4). Current balance of ammunition 4 on a TANK. 

OHS (ON-HAND 5). Current balance of ammunition 5 on a TANK. 

OQH6(ON-HAND 6). Current balance of ammunition 6 on a TANK. 

Peenor.LOSS(PLATOON COMBAT LOSS). Attribute of a PCL.V.ITEM 
indicating whether the need for an ammo type is still 
viable. 

P.RND.CNTR(PLATCON ROUND COUNTER). Argument of event 
eee Lt. AMMO pointing to the platoon currently updating. 

P-SHORT (PLATOON SHORTAGE). Attripute of a PCL.V.ITEM holding 
the quantity of that ammo the platoon is currently 
short. 

Pee (PLATOON AMMUNITION CODE). Attribute of a PCL.V.ITEM 
which points to a specific ammo type fired by the 
platoon. 

PAMMO. LON(PLATOON AMMUNITION LEVEL OF NEED). Attribute of a 
PCL.V.ITEM indexing the platoon's overall need for an 
ammo type. 

Pegnra. LOAD(PLATOON CURRENT LOAD). Attribute of a PCL.V.ITEM 
holding the platocn leader's knowledge of the on-hand 
balance for rounds of a particular type. 

PNOMEN (DLATOON NOMENCLATURE). Attribute of a PCL.V.ITEM 


containing the nomemclature of a particular ammo. 
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memes. LOAD(PLATOON BASE LOAD). Attribute of a PCL.V.ITEM 
holding the total number of rounds the platoon needs to 
b2 at optimal fill for that type ammunition. 

PLTLDR (PLATOON LEADER) (*). Attribute of a TANK. 

POINTER (*). Contains the machine address of a particular 
TANK. 

RAC(RESUPPLY AMMUNITICN CODE). Attribute of an SCL.V.ITEM 
which points to a specific ammo type carried by the 
Supply unit. 

RCNVY (RESUPPLY CONVOY). Argument of event BN.ARRIVE pointing 
mana Specific convoy. 

feo. PKG (ROUNDS PACKAGE). Attribute of a SCL.V.ITEM 
specifying the number cf rounds on an ammo pallet. 

meeuestOR. Attribute of a RES.REQ pointing to the requestirg 
wrat. 

RFILL(RESUPPLY FILL). Attribute of a RES.REQ specifying tne 
amount of ammunition released to fill a request. 

RND.CNTR (ROUND COUNTER). Argument of event UP.W. AMMO 
Peenting to the TANK currently updating. 

RP{RELEASE POINT). Attribute of a CONVOY specifying its 


destination. 
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Meer (nReOUEST POINTER). Attribute of a RES.REQ containing 
li+s pointer value. 

MeeNTR(RES.REQ POINTER). Attribute of T.CGO which points to 
the RES.REQ the supplies are meant to fill. 

Mery (RESUPPLY QUANTITY). Attribute of a RES.REQ holding the 
total quantity requested by a unit. 

fren SESUPPLY AMMUNITION CODE). Attribute of a RES.REQ which 
points to a specific ammo being requested. 

Peer ocUPPLY AMMUNITION CODE). Attribute of a SCL.V.ITEM 
pointing to the particular ammo carried by the supply 
ind t 

SeeeoN. Attribute of a RES.REQ indicating whether a RES.REQ 
has been looked at during an S-4 update. 

SLOAD1(STOWED LOAD 1). Attribute of a TANK specfying the 
optimal load for ammo type 1. 

SLOAD2 (STOWED LOAD 2). Attribute of a TANK specfying the 
optimal load for ammo type 2. 

SLOAD3 (STOWED LOAD 3). Attribute of a TANK specfying the 
optimal load for ammo type 3. 

SLOAD4 (STOWED LOAD 4). Attribute of a TANK specfying the 


optimal load for ammo type 4. 


AAS, 





SLOADS (STOWED LOAD 5). Attribute of a TANK specfying the 
optimal load for ammo type 5. 

SLOAD6 (STOWED LOAD 6). Attribute of a TANK Specfying the 
opzimal load for ammo type 6. 

SP(START POINT). Attribute of a CONVOY specifying its 
Sea gin. 

SPACE. Attribute of a CONVOY holding the amount of loading 
space available on trucks in the convoy. 

SemEORTTY (SUPPLY PRIORITY). Attribute of a RES.REQ 
specifying the urgency of need for the ammo request. 
SUPOFF (SUPPLY OFFICER) (*®). Attribute of a resupply vehicle. 
Seow lYPE({SYSTEM TYPE) (7). Attribute of a TANK specifying the 

general system type of the entity. 


TANK 

Mounted Infantry 
Desmountred Lirtantry 
Aiea ex y 

ALT 

Airc Defense 


Sao ee 
Comm/EW/Acg/iIntel 
Other 


WONIWUIE GN) as 


TCU (TRUCK CUBE). Attribute of a TANK holding the maxinun 
cube loaded on a truck. 

Memen({rTRUCK POINTER). Attribute of a T.CGO pointing to che 
truck it is loaded on. 

Memedt.CGO QUANTITY). Attribute of a T.CGO containing the 


quantity loaded as cargo. 
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TRAC(T.CGO RESUPPLY AMMO CODE). 


Meee e Or F,CGO pointing 


to the ammo type loaded as cargo. 


TWIT (TRUCK WEIGHT). 


Attribute of a TANK holding the maxinua 


heagme i= Can Carry. 


ork . 


is initiated at the company. 


WLONT(WEAPON LEVEL OF NEED 1). 


AMMO1. 
WLON2 (WEAPON 
AMMO2. 
WLON3 (WEAPON 
AMMO3. 
WLONG (WEAPON 
AMMOG, 
WLONS (WEAPON 
AMMOS. 
WLON6 (WEAPON 


AMMO6. 


LEVEL 


LEVEL 


LEVEL 


LEVEL 


LEVEL 


OF 


OF 


OF 


OF 


OF 


NEED 


NEED 


NEED 


ESD 


NEED 


WPN.TYDS (WEAPON TYPE) (%). 


a). 


Bi. 


4). 


5) 5 


6). 


Weapon 


Weapon 


Weapon 


Weapon 


Weapon 


Weapon 


system 


Sy stem 


systen 


sy sten 


systen 


systen 


urgency 


urgency 


urgency 


urgency 


urgency 


urgency 


Ot 


oak 


Hetpipucte Of a RES.REQ Containing the time a reguest 


need 


necd 


need 


need 


Attribute of a TANK specifying che 


specific weapon system within a SYS.TYPE(SYSTEM TYPE). 


WT.PKG (WEIGHT PACKAGE). Attribute of a SCL.V.ITEM specifying 


the weight of a pallet of the ammo being considered. 
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9. sets 
The sets used in the model are listed and defined as 

EOLlows: 

C.CGO.LIST (CONVOY CARGO LIST). Owned by a CONVOY. Members 
aoe RES.REOQS. 

CO.AMMO (COMPANY AMMUNITION). Owned by a COMPANY.COMMANDER. 
members are the unit's CCL.V.ITEMS. 

CO.UNIT (COMPANY UNIT). Owned by a COMPANY.COMMANDER. Members 
are unit PLATOON. LEADERs. 

CARGO (TRUCK CARGO). Owned by a supply vehicle. Members are 
the supplies(T.CGO) loaded. 

CWANT.LIST (COMPANY WANT LIST). Owned by a COMPANY.COMMANDER. 
Attributes are the unit's outstanding resupply requests. 

ELEMENTS. Owned by a convoy. Members are TANKs in the 
convoy. 

PLAT.UNIT(PLATOON UNIT). Owned by a PLAYOON. LEADER. Members 
are unit combat vehicles. 

PLT.AMMO (PLATOON AMMUNITION). Owned by a PLATCON. LEADER. 
Members are the platoon PCL.V.ITEMS. 

S.AMMO (SUPPLY AMMUNITION). Owned by a SUPPLY.OFFICER. 


Members are the supply unit's SCL.V.ITEMS. 
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S.UNIT (SUPPLY UNIT). Owned by a SUPPLY.OFFICER. Members are 
imat Supply trucks. 

SCONVOY (SUPPLY CONVOY). Owned by a SUPPLY.OFFICER. Members 
are convoys dispatched by the supply unit. 

moon. LIST (SUPPLY REQUISITION LIST). Owned by a 
SUPPLY.OFFICER. Members are the supply unit's 
outstanding RES.REQs sent to the ATP. 

SUP.OFF (SUPPLY OFFICER). Attribute of TANK pointing to its 
eoply officer. 

Svat. LIST(SUPPLY WANT LIST). Owned by a SUPPLY. OFFICER. 
Members are RES.REQs from «he combat units. 

TNK.ALIVE(TANK ALIVE) (*). Owned by the system. Members are 


mempeles still alive within the sSinulation. 


The qlobal variables used in the model aré either 
alpha, integer or real. An explanation of their use is as 
follows: 

Global _ Variables (ALPHA) 
NOMEN (NOMENCLATURE). Specifies the names of the rounds 


played. 
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CCODE(COMPANY CODE). Holds the pointer value for a company's 
Sere. LISMs 

CNUM(COMPANY NUMBER) (*). Specifies the number of 
COMPANY.COMMANDERS created. 


CSTREAM (COMPANY STREAM). Specifies the random number strean 


Ih 


Weed =cr company calculations. 

N.SYS(NUMBER OF SYSTEMS). Specifies the number of weapon 
systems created for the simulation. 

N. TANKS (NUMBER OF TANKS). Specifies the number of vehicles 
created for the simulation. 

N.WPN.TYPES(NUMBER OF WEAPON TYPES). Spvecifies the number of 
weapons created for the simulation. 

SeopE(PLATOON CODE) (2-d). Holds the pointer value for a 
Beacoon’'s PCL.V.ITEMS. 

PNUM (PLATOON NUMBER) (®). Specifies the number of 
PoatOON. LEADERS created for a sinulation. 

PSTREAM(PLATOON STREAM). Specifies the random number strean 
me OC used for platoon calculations. 

MeepE{REQUEST CODE) (2-d). Holds the pointer value for 
resupply requests created. 

RSTREAM (RESUPPLY STREAM). Specifies the random number stream 


=o be used for resupply calculations. 
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SCODE(SUPPLY CODE) (2-d). Holds the pointer value for a 
Sumo lLy Uhait's SCL.V. ITEMS. 

SNUM(SUPPLY NUMBER). Specifies the number of SUPPLY.OFFICERsS 
created for a simulation. 

TSTREAM(TRIP STREAM). Specifies the random number stream to 
be used for movement calculations. 

WSTREAM (WEAPON STREAM). Specifies the random number strean 
to be used for weapon update calculations. 


B.END(BATTLE END). Holds the termination time for a day's 


C.LIPCT (CRITICAL LON?i PERCENTAGE). Holds the maxinmun 
percentage that LON1 requisitions may be reduced to in 
order to release space on a convoy for other critical 
LON1 and LON2 requests. 

C.L2CU (CRITICAL LON2 CUBE). Holds the maximum percent of 
cube that LON2 requisitions may be cut to in order to 
release spac2 on a convoy for other critical LONi and 


LON2 requisitions. 
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C.L2WT(CRITICAL LON2 WEIGHT). Holds the maximum percent of 


weight that LON2 requisitions may be cut to in order to 


release space on a convoy for other critical LON1 and 


mONZ Fequisitions. 


CMAX(COMPANY MAXIMUM). The maximum time that can elapse 


before a company will update its ammunition status. 


CMIN(COMPANY MINIMUM). 


The minimum time that can elapse 


before a company will update its ammunition status. 


SOMLON (COMPANY LEVEL OF NEED) (2-d). Array holding the value 


of a COMPANY.COMMANDER's cutoff percentages for the five 


levels of need which can be assigned. Dimensioned as 


Mek -CL. V¥V.LTEMS (MAX 
MAXTRIP(MAX TRIP). The 
reach its intended 
MINTRIP(MIN TRIP). The 


reach its intended 


CLASS V ITEMS) by 5. 

maximum time reguired for a convoy to 
destination. 

Minimum time required for a convoy to 


destination. 


PLTLON (PLATOON LEVEL OF NEED) (2-d). Array holding the value 


Of a PLATOON.LEADERS's cutoff percentages for the five 


levels of need which can be assigned. Dimensioned as 


Wee .-CL.V.ITEMS (MAX CLASS V ITEMS) by 5. 


PMAX(PLATOON MAXIMUM). 


The maximum time that can pass before 


a platoon will update its ammunition status. 
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PMIN(PLATOON MINIMUM). The minimum time that can pass before 
a Dlatoon will update its ammunition status. 

POD (PROBABILITY OF DAMAGE) (2-d). Array holding the 
probability of damage for the varlous weapon types and 
types of damage. Dimensioned N.WPN.TYPES (NUMBER OF 
WEAPON TYPES) by 4. 

Por tPROBABILITY OF FIRE) (2-@). Array holding the probability 
of firing for the various weapon types and ammunitions 
fired. Dimensioned N.WPN. TYPES (NUMBER OF WEAPON TYPES) 
by 4. 

BOP(RATE OF FIRE) (2-d). Specifies the rates of fire for the 
Six weapons of any weapon system. Dimensioned 
N.WPN. TYPES (NUMBER OF WEAPON TYPES) by 6. 

WMAX(WEAPON MAXIMUM). The maximum time that can pass before 
a weapon will update its ammunition status. 

WMIN(WEAPON MINIMUM). The minimum time that can pass before 
a weapon will update its ammunition status. 

WPNLON (WEAPON LEVEL OF NEED) (2-d). Array holding the value 
of a weapon system's cutoff percentages for the five 
levels of need which can be assigned. Dimensioned as 


MAX.CL.V.ITEMS (MAX CLASS V ITEMS) by 5. 
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WN BmBOVDOw~AAN EWN 2 OW OWWIANE WN 3 O OO ANNE WD BO DO WYODUNIE WN OW OADM EW BOW OnIQNUIE WD 


ANDAADIMANNININIUINA NE See eee SS WWWwWwWWWwWWWRHNDNDNDDD PDD of 8 at et a a 


1 PREAMBLE 
DEFINE WPNLON,PLTLON,AND COMLON AS REAL,2-DIM ARRAYS 
DEFINE ROF AS INTEGER, 2-DIM ARRAY 
DEFINE NOMEN AS AN ALPHA,1-DIM ARRAY 
DEFINE PLACES AS A 2-DIu "INTEGER ARRAY 
DEFINE POD AS REAL,2-DIM ARRAY 
GENERATE LIST See ae 
THE SYSTEM OWNS SOME TNK.ALIVE 
ee 
PERMANENT ENTITIES 
EVERY COMPANY.COMMANDER HAS AN N.CCL.V.ITEMS, 

AN SG.OFF,A REON, 
OWNS A CO.UNIT,A CWANT.LIST,AND SOME CO. AMMO 
DEFINE N.CCL.V-ITEMS,S4.OFF,REON AS INTEGER 


i VARIABLES 


Byeon’ EDATOONA LEADER HAS A PCO.CDa,aN N.PCL.YV.ITEMS, 
MAY BELONG TO A CO.UNIT, 

AND MAY OWN A eae UNIT, AND A PLT.AMMO 

DEFINE Pe 6 CU igen s Cue V.ITEMS AS INTEGER VARIABLES 


EVERY SUPPLY. OFFICER HAS A SCO.CDR,A N.SCL.V.ITEMS, 
OWNS SOME S.AMMO UNIT,AN SWANT.LIST, 

AN SREON.LIST, AnD” AG ” ScoNvS 

DEFINE SCO.CDR, N.SCL.V.ITEMS AS INTEGER VARIABLES 


TEMPORARY No eS 
EVERY TANK HAS A NAME,A COLOR,A SYS.TYPE,A WPN.TYPE, 


A POINTER,AN AP.TOW,AN HE.DRAG,AN AW1-.OR. MSL3, 
AN AW2.OR. ADM, AN ANHOS AN AMMO6 
A SLOADI,A SD Ek LOAD3 ,A SLOADG,A SLOADS, 
A SLOAD6,AN OB ate oF AN 643" AN OH4,AN OH5S,AN OH6, 
A WLONI,A WLONZ, WLONS A WLONG, A WLONS,A WLONG, 
AN TAC1,AN TAC aN TAC3, AN TACG,AN TACS, AN TAC6, 
A pLALDA yA COCDR, A SUPOFPF,A MAX. WI,A MAX.CUBE, 
AN MK£LL,AN FKILL,AN MFKILL,A KKILL, 
AND MAY BELONG TO A TNX.ALIVE,A PLAT.UNIT,A S.UNIT, 
AND A ELEMENTS,AND MAY OWN SOME CARGO 
DEFINE N.TANKS AS AN INTEGER VARIABLE 
DEFINE NAME,COLOR SYS. TYPE, WEN. TYP= SUP. OFF, POINTER, 
AD. TOW, HE.DRAG,AW1.OR. MSL3,AW2.OR. ADM, AMMO5,AMMOO, 
SLOAD1 SLOAD2 -§LOAD3 SLOA Be erases ,SLOADG6, 
OH 1,0H2,0H3,0H84,0HS ae. 
WLON1,WLON2,WLON3, WLONG.WLONS, WLONG, 
TACIT, TAC2, TAC3,TACU, TACS,TA 
BLTLDR, COCDR, SUROFF, MAX at - MAX.CUBE, 
y+ 
MKILL,PRILL,MFKILL,AND KKILL AS INTEGER VARIABLES 
EVERY T.CGO HAS A TPNTR, a RRPNTR, A TRAC, A TNOMEN, 
A TOTY,AND MAY BELONG TO A CARGO 
DEFINE TPNTR, RRPNTR, TRAC Tory AS INTEGER VARIABLES 
DEFINE TNOMEN AS AN ALPHA VARIABLE 
EVERY CONVOY HAS AN SP,AN RP,A CONTRKS,A SPACE 
C.MV.STATE, A CPNTR,MAY BELONG TO A SCONVOY,MAY OWN 
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134 EVERY MOVE HAS A MARCH.ORDER 
135 EVERY CO.RESUPPLY.ARR HAS A CO.CNVY 
136 EVERY BN.ARRIVE HAS AN RCNVY 
137 EVERY REDISTRIBUTE HAS A DISTR 
138 EVERY FIREKILL HAS A VICTIM 
139 DEFINE VICTIM,RND.CNTR,P.RND.CNIR,C. RND. CNTR, ISSUER, 
140 ISSUBE,CO.CNVY,MARCH.ORDER,RCNVY,AND DISTR 
141 AS INTEGER VARIABLES 
Be. MATNT 


The purpose of the main program is to call routines that 
create blue forces, to schedule the events that generate 
Meta, and to start/stop the simulation. 

EVENT NOTICES 
Beue.DATE(BATTLE UPDATE), BAT.L.TIMZ(BATILE TIME), 
STOP.SIMULATION 


SIM.STOP Holds the time for Simulation termination. 


ROUTINES CALLED 





BLU.CREATE 


: MAIN 

¢ 9 

3 ODEPINE SIM.STOP AS A REAL VARIABLE 
4 READ SIM.STOP 

Se OCHEDULE A STOP.SDIMULATION IN SIH.STOP DAYS 
Mee one 2 CARDS 

7 CALL BLU.CREATE 

9 SCHEDULE A BAT.L.TIME NOW 

mw SCHEDULE A B.UP.DATE NOW 
mo)6OM PRINT)uU61 6 LINE THUS 

STA SIMULATION 

fee SLART SIMULATION 
iz STOP 
13. END 


meme, S Defines recursive variables used in the routine. 
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Line 4 Reads Simulation stop time. 

Line 5 Schedules the event STOP.SIMULATION. 

Line 7 Calls routine 5LU.CREATE. 

Line 8 Schedules the first BAT.L.TIME event. 

Line 9 Schedules printing of the first battie summary. 
Lin2 10 Prints a statement to mark Simulation start. 


Line 11 System conmand to start the Simulation. 


eee "ROUTINE BLU.CREATS" 

Routine BLU.CREATE is called from the main program to 
Meet the sntities of each blue unit. Arter creating these 
entities, it establishes their attributes and files each 
Piercy in its appa semi e Gee 

EVENTS _ SCHEDULED 


UP.W.AMMO(UPDATE WEAPON AMMO). 


G) 


GLOBAL VARIABLES (INTEGER) 

CNUM(COMPANY NUMBER). Specifies the number of 
COMPANY.COMMANDERS created. 

CSTREAM (COMPANY RANDOM NUMBER STREAM). 

N.COMPANY.COMMANDERS (NUMBER OF COMPANY COMMANDERS). 

N.PLATOON. LEADERS (NUMBER OF PLATOON LEADERS). 

NoeSUPPLY.OFFICERS (NUMBER OF SUPPLY OFFICERS). 


N.TANKS (NUMBER OF TANKS). 


PNUM(NUMBER OF PLATOONS). 
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PSTREAM (PLATOON RANDOM NUMBER STREAM). 
SoM (NUMBER OF SUPPLY OFFICERS). 
CMAX(COMPANY MAXIMUM). The maximum time that can pass before 
a company will update its ammunition status. 
CMIN(COMPANY MINIMUM). The minimum time that can pass before 
a company will update its ammunition status. 
PMAX(PLATOON MAXIMUM). The maximum time that can pass before 
a platoon will update its ammunition status. 
PMIN(PLATOON MINIMUM). The minimum time that can pass before 
a platoon will update its ammunition status. 
WMAX(WEAPON MAXIMUM). The maximum time that can pass before 
a weapon will update its ammunition status. 
WMIN(WEAPON MINIMUM). The minimum time that can pass before 
a weapon will update its ammunition status. 
Seman wee eNe The S 


COMPANY.COMMANDER, PLATOON.LEADER, SUPPLY.OFFICER 


N.CCL.V.ITEMS. Number of company class YV items (unique to a 
company commander). 
N.PCL.V.ITEMS. Number of platoon ciass V items(UNIQUE TO A 


PLATOON LEADER). 
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N.SCL.V.ITEMS. Number of supply class V items (UNIQUE TO A 
SUPPLY OFFICER). 

PCO.CDR. (PLATOON COMPANY COMMANDER). 

SCO.CDR. (SUPOLY COMPANY COMMANDER). 


Peo rr. (COMPANY S-4 OFFICER). 


m= Loop index. 


ROUTINES CALLED 


== a ee ee De ee a Ee 


BASEC.LOAD, PARAMETERS 


of 


nn 


CO.UNIT (COMPANY UNIT). Owned by a COMPANY.COMMANDER. 
Members are the unit's PLATOON.LEADERs. 

PLAT.UNIT(PLATOON UNIT). Owned by a PLATOON. LEADER. Members 
acre the unit's combat vehicles(TANKs). 

S.UNIT (SUPPLY UNIT). Owned by a SUPPLY.OFFICER. Members are 
the unic's supply vehicles (TANKs). 

TINK.ALIVE(TANK ALIVE). Owned by the system. Members are 
vehicles still alive within the simulaticn. 

EMPORARY ENTITIES 

TANK. temporary entity used to represent all vehicles on 
the battlefield. Its attributes distinguish the 


individual vehicles as to type and function. 


ga 


MPORARY ATTRIBUTES (INTEGER) 


a eet ee ce ——_———_ SS = an 6 See Gp ee 
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AMMOS (AMMUNITION 5). 


AMMO6 (AMMUNITION 6). 


AP. TOW (ARMOR-PIERCING/TOW) . 


TAC1. (TANK 
TAC2. (TANK 
TAC3. (TANK 
TACY. (TANK 
TACS. (TANK 
TAC6. (TANK 


AW1.08. 


AMMUNITION 


AMMUNITION 


AMMUNITION 


AMMUNITION 


AMMUNITION 


AMMUNITION 


MSL3(ALTERNATE 


Ammunition 1. 
CODE i) 
CODE 2). 
CODE os). 
CODE 4). 
CODE 5). 
CODE 6). 


WEAPON 1 OR MISSILE 3). Ammunition 3. 


Meee OR. ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE). 


Ammunition 4. 


COCDR (COMPANY COMMANDER). 


COLOR 


membership. 


HE.DRAG (HEAT/DRAGON ROUNDS). 


This a@eribute of a TANK 


VO ndacates REDeFORCE, 


Of a TANK. 
indicates the TANK's force 
indicates BLUE. 


he 


Ammunition 2. 


MAX.CUSE. Indicates the max cargo cube a resupply 


vehicle(TANK) is designed to move. 


MAX.AT. 


Indicates the max cargo weight a resupply 


vehicle (TANK) is designed tc move. 


NAME. 


PLTLDR (PLATOON LEADER). 


POINTER. 


Indicates 


the number of a TANK in the battle. 


Of TANK. 


Combat vehicle's machine address. 
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RND.CNTR (ROUND COUNTER). Argument of routine W.AMMO(WEAPON 
AMMUNITION) carrying the value cf the TANK updating. 

SLOAD1(STOWED LOAD 1). Optimal load ammo type 1. 

SLOAD2 (STOWZD LOAD 2). Optimal load ammo type 2. 

SLOAD3 (STOWED LOAD 3). Optimal load ammo type 3. 

SLOAD4Y (STOWED LOAD 4). Optimal load ammo type 4. 

SLOADS (STOWED LOAD 5). Optimal load ammo type 5. 

SLOAD6 (STOWED LOAD 6). Optimal load ammo type 6. 

SUPOFFP (SUPPLY OFFICER). OF TANK. 

Beet YPE(SYSTEM TYPE). Of TANK. 

TWE (TRUCK WEIGHT). Maximum cargo weight for a vehicle. 

TCU(TRUCK CUBE). Maximum cargo cube for a vehicle. 


WPN.TYPZ (WEAPON TYPE). Of TANK. 


RND.CNTR (ROUND COUNTER). Argument of routine W.AMMO (WEAPON 
AMMUNITION) carrying the value of the TANK updating. 
PROGRAM LISTING 


ROUTINE BLU.CREATE 
11 
DEFINE IT AS AN INTEGER VARIABLE 
PRINT 1 LINE THUS 
»  eOUTINE BLU.CREATE 
WMIN, WMAX,WSTREAM 
2S Ron 
READ PMIN, PMAX,PSTREAM 
2 CARDS 
READ CMIN,CMAX,CSTREAM 


DBOOWNNN BWN 
ee 
ty 
ao) 
8 


—s 
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80 END 
EXPLANATION OF CODE 
Line 3 Defines recursive variables for the routine. 
Line 4 Prints message to mark the start of the routine. 
Lines 6-13 Read and print out data establishing min and max 


times entities will check their ammo status as well as 


Wm 


randcm number streams for calculations. 

Lines 15-17 Establish the number of company commanders, 
platoon leaders, and supply officers to be created in 
the simulation and print out the information input. 

Line 18 Calls routine PARAMETERS. 

Lines 19-27 Create the specified number of company 
commanders, and read the attributes of each and print 
eae information. 

Lines 29-38 Create the specified number of piatoon leaders, 
read their attributes, file them in appropriate sets and 
Beant the information. 

Lines 40-48 Create the specified number of supply officers, 
read their attributes, file them in appropriate sets and 
meant the information. 


Line 49 Calls routine BASIC.LOAD. 
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Line 52 Reads the number of TANKs to be created for the 
Simulation. 

Lines 53-78 Create the spécified number of TANKS read their 
attributes, file <hem in appropriate sets and print the 
Zee OcmatioOn. 

Line 71 Schedules an UP.W.AMMO event for each TANK to 


initially set ammunition status. 


meee “ROUTINE PARAMETERS" 

ROUtine PARAMETERS is called from routine BLU.CREATE +o 
reserve space for and read vaiues into the following arreys: 
WPNLON, COMLON, NOMEN, ROF, POF, and POD. Additionally the 
Mmeececal cutoff values for supply action(c.L2WT, C.L2C, 
meeeectT, and C.L?IPCT), the trip times to and from the supply 
points (MINTRIP and MAXTRIP), and the random number Streams 
TSTREAM and RSTREAM ate established. 

GLOBAL_VARIABLES_ (ALPHA) 


NOMEN (NOMENCLATURE) .Array specifying the name of rounds 


played. 


CNUM(COMPANY NUMBER). Specifies the number of 


COMPANY. COMMANDERS created. 
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RCODE(RESUPPLY CODE) (Z-d). Holds the pointer vaiue for a 
supply unit's SCL.V.ITEMS(SUPPLY CLASS V ITEMs). 

ROF (RATE OF FIRE) (2-d). Specifies the rates of rire for the 
six weapons of any weapon system. 

RSTREAM(RESUPPLY STREAM). Specifies the random number stréean 
*o be used for resupply calculations. 

TSTREAM (TRIP RANDOM NUMBER STREAM). 

GLOBAL_VARIABLES (REAL) 

C.LIPCT (CRITICAL LON1 PERCENTAGE). Holds che maxinua 
percentage that LON1 requisitions may be reduced to in 
order to release space on a convoy for other critical 

\ 
LON? and LON2 requests. | 

C.L2CU (CRITICAL LON2 CUBE). Holds the maximum percent of 
cube LON2 requisitions may be cut to in order to release 
space on a convoy for cther critical LON1 and LON2 
requisitions. 

C.L2PCT(CRITICAL LON2 PERCENTAGE). Holds the maxinun 
percentage that LON2 requisitions may be reduced to in 
order to release space on a convoy for other critical 
LON? and LON2 requests. 


C.L2.4T (CRITICAL LON2 WEIGHT). Holds the maximum percent of 


cube LON2 requisitions may be cut to in order to release 
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Space on a convoy for other critical LON1 and LON2 
requisitions. 

COMLON (2-d) (COMPANY LEVEL OF NEED). 

MAXTRIP(MAX TRIP). The maximum time required for a convoy to 
reach its intended destination. 

MINTRIP(MIN TRIP). The minimum time required for a convoy to 
reach its intended destination. 

PaoEON (2-d) (PLATOON LEVEL OF NEED). 

POD (2-d) (PROBABILITY OF DAMAGE). For all weapon systems 
played. 

POF (2-d) (PROBABILITY OF FIRE). For all weapon systems 
played. 

WPNLON (2-d) (WEAPON LEVEL OF NEED). 


RECURSIVE VARIABLES (INTEGER) 





Mea eCL.V.UTTENS(MAX NUMBER OF CLASS V ITEMS PLAYED). 
Meee N. TYPES(NUMBER OF WEAPON TYPES). 


PROGRAM LISTING 


1 ROUTINE PARAMETERS 
2B ' 
3 PRINT 1 LINE THUS 
ROUTINE PARAMETERS 
4 DEFINE MAX.CL.V.ITEMS,AND N.WPN.TYPES 
> AS AN INTEGER VARIABLES 
Smee AD MAX.CL.V.IT 2 
fee ol AX. CLV. ITEM 
s SKIP 3 CARDS 
Moe RESERVE WPNLON(™,=) AS MAX.CL.~V.ITEMS BY 5 
171 READ WPNLO 
fee SKIP 3 CARDS 
ie LIST WPNLON 
Ramer ooonv Eh PLILON (®,*) AS MAK.CL.V.ITEMS BY 5 
15 READ PLTLON 
16 SKIP 3 CARDS 
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LIST PLTLON 
RESERVS COMLON(*,%) AS MAX.CL.V.ITEMS BY 5 
READ COMLON 

SKIP 2 CARDS 

LIST COMLON 

RESERVE NOMEN (*) AS MAX.CL.V.ITEMS 

READ NOMEN 


Sie P 2 CARDS 
LIst NOMEN 


READ N.WPN.TYPES Peo Newer Ns DY PES 


Sealer 3 CARDS 

RESERVE ROF AS N.WPN.TYPES BY 6 
READ ROF 

SEP 3. CARDS 

LIst nOF 


RESERVE POF AS N.WPN.TYPES BY 6 
READ POF 

Stre SaGARDS 

List EON 


RESERVE POD AS N.WPN.TYPES BY 4 
READ POD 

Sica? 2 CARDS 

LIst POD 


‘tRESERVE AN ARRAY TO HOLD RESUPPLY REQUESTS 
RESERVE RCODE(*,%) AS CNUM BY 6 


“ Set UP ee ate CUurOrr ee FOR S-4 


READ C.L2WT cor aeue€ CsLZPCr,C.L1Pcr 
aes .L2uT, ~L2CU, C.L2pCT, ~LIPCT 
Sh EP 5 CARDS” 

READ MINTRIP, MAXTRIP,TSTREAN, RSTREAM 
Elon wri NC REP;SMAXTRIP,TSTREAM, RST REAM 
SKIP Z5CARDS 

RETURN 

END 


MAINA ne e&eb ee eee ewww wWWwW WWWNNNPN VONNNN a= 
CO NIDNNE WN = OOO DNDN WN OOD ANNE Wp) OO DO INU ES Wp 2@OwWo~) 


Line 3 Prints a message specifying the start of the 


=sou- ine. 


Lanes 4-5 Define recursive variables for the routine. 


Lines 6-7 Read and print out the max number of ammunition 


=ypes to be played in the simulation. 


Lines 10-21 Reserve space for and read the threshold values 


for the level of need played at the weapon, platoon, and 


company levels in the simulation. 
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Lines 23-26 Reserve an array for and read in the 
nomenclatures played. 

Line 28 Reads the number of weapon types played. 

Lines 31-44 Reserve space for, assign values to, and print 
out the arrays used in the battle computations. These 
artays are: Rate of Fire; Probability of Fire; and 
Eeovability of Damage. 

Lines 46-47 Reserve space to hold values of resupply 
requisitions created by each company in th2® simulation. 

Lines 49-51 Read in the critical cutoff values for resupply 
action. These values are: Critical LON2 weight; 
Merescal LONZ cube: Critical LON2 Percent; and Critical 
LON1 percent. 

Lines 53-54 Read in the min and max times required to 


travel between the supply point and the company. 


fee SOUTINE BASIC.LOAD" 

Pemeine BASIC.LOAD is called from routine BLU.CREATE to 
create the base ammunition assets of all platoons, 
companies, and supply officers in the model. 

EVENTS CALLED 


UP.COM.AMMO(UPDATE COMPANY AMMO). 


UP.PLT.AMMO(UPDATE PLATOON AMMO). 


Hest 





GLOBAL _VARIABLES_(ALPHA) 
NOMEN (NOMENCLATURE). Specifies name of round. 
GLOBAL_VARIABLES (INTEGER) 
CCODE (COMPANY CODE) (2-d). Holds the pointer value for a 
eompany’s CCL.V.ITENS (COMPANY CLASS V ITEMs). 
CNUM(COMPANY NUMBER). Specifies the number of 
COMPANY.COMMANDERS created. 
PCODE (PLATOON CODE) (2-d). Holds the pointer value for a 
Sraceen s PElwv. LTEus (PLATOON CLASS V¥V ITEMs). 
PNOM(PLATOON NUMBER). 
SCODE (SUPPLY CODE) (2-d). Holds the pointer value for a 
eiopny Unit's SCL.V.ITEMS{SUPPLY CLASS V ITEWMs). 
Sut ( NUMBER OF SUPPLY OFFICERS). 
PERMANENT ATTRIBUTES (INTEGER) 
N.CCL.V.ITEMS. Number of company class V items(UNIQUE TO A 
COMPANY.COMMANDER). 
N.PCL.V.ITEMS. Number of platoon class V items(UNIQUE TO A 
PLATOON. LGADER). 
N.SCL.V.ITEMS. Number of supply class V items (UNIQUE TO A 
ewe PLY. OFFICER). 
RECURSIVE VARIABLES (INTEGER) 


ee a) a ee ee ee a a A a 


mere, S - LOOp indicies. 
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CO.AMMO (COMPANY AMMUNITION). Owned by a COMPANY. COMMANDER. 
Members are the unit's CCL.V.ITEMS (COMPANY CLASS V 
fee MS) 

PLT.AMMO (PLATOON AMMUNITION). Owned by a PLATOON. LEADER. 
Members are the unit's PCL.V.ITEMS (PLATOON CLASS V 
me eS) 

S.AMMO(SUPPLY AMMUNITION). Owned by a SUPPLY.OFFICER. 
Members are the unit's SCL.V.ITEMS (SUPPLY CLASS V ITEMS) 

TEMPORARY ENTITIES 

mee Vv. LTEM. (COMPANY CLASS V ITE). 

Meise’. L TEM. (PLATOON CLASS V ITEM). 

beL.V.LITEM. (SUPFLY CLASS V ITEM). 

C.RND.CNTR (COMPANY ROUND COUNTER). Argument for event 
UP.COM.AMMO (UPDATE COMPANY AMMUNITION) holding a 
pointer of a company unit. 

CNOMEN (COMPANY NOMENCLATURE). This attribute of a 
CCL.V.ITESM (COMPANY CLASS V ITEM) contains the name of 
the particular ammunition. 

PNOMEN (PLATOON NOMENCLATURE). This attribute of a 


PCL.V.ITEM( PLATOON CLASS V ITEM) contains the name of 


the particular ammunition. 
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SNOMEN (SUPPLY NOMENCLATURE). This attribute of a 


SCL.V.ITEM(SUPPLY CLASS V ITEM) contains tne name of the 
particular ammunition. 

CAC (COMPANY AMMUNITION CODE). 

ONHAND (INTEGER). This attribute cf a SCL.V.ITEM (SUPPLY 
CLASS V ITEM) holds the on-hand baiance of stocks for an 
ammunition. 

P.RND.CNTR (PLATOON ROUND COUNTER). Argument of the event 
UP.PLT.AMMO(UPDATE PLATOON AMMUNITION) carrying the 
pointer value of the piatoon currently updating. 

PAC (PLATOON AMMUNITION CODE). Of a PCL.V.ITEM(PLATOON CLASS 
oo. TEM) 

RDS.PXG (ROUNDS PER PACKAGE). Number packed per pallet of an 
Bel. Ve. LTEM(SUPPLY CLASS ¥V ITEM) . 

SAC (SUPPLY AMMUNITION CODz). 

SUS PKG (CUBE PACKAGE). Cube of ammo pallet for an SCL.V.ITEM 
Meo P PLY CLASS V ITEM). 

WI.PKG (WEIGHT PACKAGE). Weight of ammo pailet for an 
Seg. ’. ELEM (SUPPLY CLASS V ITEM). 


le ROUTINE BASITC.LOAD 
Pee Serine 1,P,S,AND C AS INTEGER VARIABLES 
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3 PRINT 1 LINE THUS 
ROUTINE BASIC.LOAD 

a 

5 '*SETUP PLATOON BASIC LOADS 

oe ee 

8 RESERVE BCODE (PAUN ,*) AS N.PCL.V.ITEMS (P) 
9 FOR I = 1,TQ N-PCL«V. ITEMS (2) , D0 

ae ale sala riapecge? Foor ceo 
12 LET PNOHEN (BCODE (P, I) ) = NOMEN(I) 

13 pobEEE PCODE(P,I) IN Put. atito (2) 

15 SCHEDULE A UP.PLT.AMMO(P) IN 1 MINUTE 
Raa 

18 ‘'SETUP COMPANY BASIC LOADS 

J9 RESERVE CCODE (#,*) AS CNUM BY * 
5 rOR ST CLCNUM N CCL. V. [TEMS C) 

22 RESERVE cco be (CHUM ,4) AS thet. v. ITEMS (C) 
D3 FOR I = 1 TO N.CCL.V.ITEMS(C), DO 
53 Let CAC(CCODE(C,I)) 2 tO 
26 LET COWEN (CODE (e,1)) = NOMEN (I) 
27 geEeE CCODE(C,1) IN’ CO. AMMO (C) 
LOOP 

29 SCHEDULE AN UP.COM.AMMO(C) IN 1 MINUTE 
B # 

32 '' SETUP SUPPLY OFFICER BASIC LOADS 

33 RESERVE SCODE (S,*) AS SNUM BY 5 

33 rors Ss SNUM,N{SCL. V.ITEMS S) 
36 RESERVE Scobs (SNUM,*) AS fsch wv. ITEMS (5) 
37 FOR I = 1 TO N.SCL.V.ITEMS(S), DO 
ggg RST 
40 LET SNOHEN (SCODE (S T)) | = NOMEN (T) 

4 READ WT. PK (Scodz (5, p CU. PKG (SCODE (ST) } 
42 READ RDS. PKG (SCODE (3,1) } , ONHAND (SCODz (5,1) ) 
43 FIL= SCODE(S,1) IN S.auh0(S) 

44 LOOP 

45 LOOP 

46 RETURN 

4W7 «END 


ae GE SE Gk ae SS eS ee, SG Sa ee eae 


Line 2 Defines recursive variables used in the routine. 

Line 3 Prints a message marking the beginning of the 
routine. 

Line 6 Reserves the first index of the ragged array PCODE 


as the number of platocns played in the Simulation. 
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PCODE will 2ventually hold the ammunition types used by 
the platoon. 

Line 7 Begins the outside loop over 2ach Platoon.Leader for 
the code segment which creates and stores the ammunition 
carried by 2ach platoon. Loop ends on line 16. 

Line 8 Reserves the second index of the ragged array PCODE 
+o hold the number of ammo types carried by each 
platoon. 

Line 9 Begins the inside loop over each ammunition type 
carrisd by a platoon. Loop ends on line 14. 

LINE 10-13 Create each ammo type carried by a platoon, 
recerd its ammunition code and nomenclature, and file 
*h2 ammo type in the platoon leader's ammo 
stocks (PLT.AMMO). 

Lineé 15 Schedules the initial update for the platoon. 

Line 19 Reserves the first index of the ragged array CCODE 
to the number of companies played in the simulation. 
CCODE will eventually hold the ammunition types used by 
+he company. 

Line 20 Begins the outside loop over each company 
commander, che cede segment which creates and stores the 
ammunition carried by each company. Loop ends on line 


BO. 
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Line 22 Reserves the second index of the ragged array CCODE 
+o hold the number of ammo types carried by each 
company. 

Line 23-28 Begin «he inside loop over each ammunition type 
carried by a company. Loop ends on line 28. 

Line 24-27 Create each ammo type carried by a company; 
record its ammunition code and nomenclature; and file 
the ammo type in the company ammo stocks (CO.AMMO). 

Line 33 Reserves the first index of the ragged array SCODE 
to the number of supply elements played in the 
Simulation. 

Line 34 Begins the outside loop over each supply officer, 
the code segment which creates and stores the ammunition 
carried by each supply unit. Loop ends on line 45. 

Line 36 Reserves the second index of the ragged array SCODE 
to hold the number of ammo types carried by each supply 
ie. t . 

Line 37 Begins the inside loop over each ammunition type 
carried by a supply unit. Loop ends on line 44. 

Lines 38-43 Create each ammo type carried by a supply unit; 
record its ammunition code, nomenclature, standard 


package weight, standard package cube, number of rounds 
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per package, starting level, and file them in the supply 


unit's ammo stocks (S.AMMOQ). 


F. "ROUTINE W.AMMO" 

Routine W.AMMO is called by events UP.W. AMMO, 
CO.RESUPPLY.ARR, and REDISTRIBUTE for each TANK in the model 
in order to update each TANK's ammunition LON. An argument, 
NO.BATTLE, is set to indicate whether battle information 
should be obtained or if only a simple update is required. 
Additionally a program indicator WFLAG, is set to provide 
information on the system's status. 

A ~ Identifies the weapon system updating its ammunition. 
NO.BATTLE. Indicates whether routine BATTLE should be 
ecauied. 


"Oo" indicates no 
"7" indicates yes 
WFLAG. Weapon status indicator. If WFLAG=100 the weapon is 


out of a particular ammunition this signals the platoon 
to do an immediate update. If WFLAG=1 the TANK has been 
knocked out of battle and should no longer update its 
ammunition status. 

DEFINE TO_MEAN 


AMMO1. AP.TOW(ARMOR PIERCING/TOW ROUNDS). 
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AMMO2. HE.DRAG (HEAT/DRAGON ROUNDS). 
PnOo3S. AWI.OR.MNSL3(ALTERNATE WEAPON 1 OR HISSILE 3). 
AMMO4. AW2.0OR8. ADM(ALTERNATE WEAPON 2 OR AIR DEFENSE 


MESSTELE). 


TIME.V 





I - Loop index. 
TEMP.LON (TEMPORARY LON). Place holder for LON computations. 
TRY Routing indicator to the ammo type being updated. 
mer(PSRCENT). 

ROUTINES CALLED 


BATTLE 


AMMOS (AMMUNITION 5). Of a TANK. 

AMMO6 (AMMUNITION 6). Of a TANK. 

AP. TOW (ARMOR-PIERCING/TOW) . Ammunition 1. 
TAC1. TANK AMMUNITION CODE 1. 

TAC2. TANK AMMUNITION CODE 2. 


TAC3. TANK AMMUNITION CODE 3. 
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TACY. TANK AMMUNITION CODE 4, 

TACS5S. TANK AMMUNITION CODE 5. 

myeo. CTANK AMMUNITION CODE 6. 

Mar.OR-MSL3(ALTERNATE WEAPON 1 OR NISSILE 3). Ammunitioa 3 
Of a TANK. 

meee OR. ADM{ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE). 
Ammunition 4 of a TANK. 

FKILL(FIREPOWER KILL). Indicates whether a TANK has 
sustained a firepower kill during the battle. 


"go" indicates no 
"7" indicates yes 
HE.DRAG(HEAT/DRAGON ROUNDS). Ammunition 2 of a TANK. 


KKILL(CATASTROPHIC KILL). Indicates whether a TANK has 
Sustained a catastrophic kill during the battle. 


"ot indicates no 
"7" indicates yes 
MKILL(MOBILITY KILL). Indicates whether a TANK has sustained 


a mobility kill during the battle. 


"QO" indicates no 
"1" indicates yes 
MPKILL (MOBILITY AND FIREPOWER KILL). Indicates whether a 


TANK has sustained a mobility and firepower kill during 
the battle. 


"QO" indicates no 
"1" indicates yes 
OH1(ON-HAND 1). Current balance of ammunition 1 on a TANK. 
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OH2 (ON-HAND 2). 
OH3 (ON-HAND 3). 
OHY(ON-HAND 4). 
OH5 (ON-HAND 5). 
OH6 (ON-HAND 6). 


POINTER 


CUELEeE HE 


Current 


CuSsEene 


Current 


Current 


balance 


balance 


balance 


balance 


balance 


PLTLDR (PLATOON LEADER) Of TANK. 


Of 


of 


of 


of 


Machine address of a TANK. 


ammunition 


ammunition 


ammunition 


ammunition 


ammunition 


Tani. 
TANK. 
4 on a TANK. 
Don a TANK. 


TANK. 


SLOAD1 (STOWED 
SLOAD2 (STOWED 
SLOAD3 (STOWED 
SLOAD4 (STOWED 
SLOAD5 (STOWED 
SLOAD6 (STOWED 
WLON1 (WEAPON 
WLON2 (WEAPON 
WLON3 (WEAPON 
WLONY (WEAPON 
WLONS (WEAPON 


WLON6 (WEAPON 


LOAD 


LOAD 


LOAD 


LOAD 


LOAD 


LOAD 


LEVEL 


LE VEL 


LEVEL 


LEVEL 


LEVEL 


LEVEL 


1). 
2a 
3). 
4). 
Des 


6). 


Optimal 


Optimal 


load 


load 


load 


Optimal load 


Optimal 


Optimal 


load 


load 


anno 


anno 


anno 


ammo 


ammo 


anno 


type 
type 
type 
type 
type 


type 6. 


OP NEED 1). 


OF 


OF 


OF 


NEED 


NEED 


NEED 


NEED 


NEED 


TEMPORARY ENTITIES 


TANK 


PROGRAM LISTING 


1 ROUTINE W.AMMO GIVEN A,AND 


2). 
3). 
4). 
5). 


6). 


Urgency 
Urgency 
Urgency 
Urgency 
Urgency 


Urgency 


woz 


of 


Or 


Oe 


Or 


Ote 


of 


need 


need 


need 


need 


need 


need 


ammunition 


ammunition 


ammunition 


ammunition 


ammunition 


ammunition 


3. 


NO.BATTLE YIELDING wFLAG 





ME Who 


a ae 
homOwWO~ 0) 


DADDAAnNNNNINNAANIN SEES SS SSW WWWWWWWWONPNMDNDNDID a at 8 2 a td ot 
WI WN) @ OW ONIONS WN OW OWOINE WD OW HO SONNE WN OOO AOD E Wu 3 OO SONU EW 


NE NO.BATILE,WFLAG,TEMP.LON AS INTEGER VARIABLES 
E PCT ats A REAL VARIABLE 
E A ND I AS AN INTEGER VARIABLES 
2 ETNEs HLTH TIME.¥ AND A AS FOLLOWS 
NT WeAMMO CALLED AT TIME. V ¥%, sam 
WEAPON OSesT EN xkaRAK DJPDATING 


IF NO.BATTLE EQ QO, 
eS BATTLE (A) 


Q 1.OR KKILL(A) EQ 1 OR MKILL(A) EQ 1 


ITH POINTER (TANK! THUS 
GE ON TANK *¥8¥ee DREVENTS 
MENT. SEQUENCE ENDED. 

‘t BATTLE DAMAGE SUSTAINED 


ear 
ee 
rape 
Ars 


rie City; 
iad 


0) 
A] 
oO Cx 


cS 


FORMATION FOR PLT.COMPUTATIONS. 


meee DI UN MW Or" 
HUN nnn Hwa 


She 
tal 
t2 
GQ OO0000 
OH RM 2G Re eaRHhH 


OQx<s AS DNISWNOAQ HUT eAHHh 


am Wil 


eanwf% G&Gin aint 


Pry OO0O0002 
“Ga ANUS Wwhes 


N 
M 


rr 


~~ 
POM PY} pi wry 


OQ Cole Ce lec bo 


t+ 

ty 

fae 

be 
i 


EET DR 
GO TO 
i fLeEt 


ier PCT= 
LET I= TA 
Pole ay = 
GO TO CHE 
V2 LET L 


LET PCT= 
LET I= T 
LET TRY = 
GO TO CHE 
3! con WL 


LET PCE 
LET I= 


C4 ted Wt 


1(A)=TEMP.LON 
BNO 2 (A) /SLOAD2 (A) 


43-0 


2(A)=TEMP.LON 
Ay, @) /Su0ans 


bo 
— 


3 (A) =TEMP.LON 

MO4 (A) /SLOAD4(A 

ey ee (A) 
4 (A)=TEMP.LON 

T Bey a) Smee (2) 


5 (A)=TEMP.LON 
MO6 (A) /SLOAD6 (A) 
(A) 

6 (A) =TEMP.LON 


'GHEC K * 
ir ee Gs Bigee sto PS 
LET TEMP.LON= 


163 





GO TO ROUTING 
ALWAYS 


IP PCT _GE WPNLON (I, aN 
LET TEMP. LON= 
GO TO ROUTING 

ALWAYS 


IF BGT GE Ae a 23), 
Ber DLESP 
GO TO ROUTING 
ALWAYS 


IF PCT GE WPNLON(I,4), 
LET TEMP. LON= 
GO TO ROUTING 


WO WO 00 00 00 09 0000 00 00 00 00 SII SII SISSON 
= OW O~YODNE WIN) = © 1 0 NINN E La = 1000 ~J OV 


ALWAYS 
IF Pema GE Ee nanie 5a) - 
LET TEMP.LON= 
LET WFLAG = 100 
ALWAYS 
Saal COP TOM, 2,554,270 PER TRY 
RETURN 
END 


EXPLANATION OF _CODE 

Line 5 Prints a message marking the start of the event and 
identifying the weapon system updating. 

Lines 7-9 Check if battle information should be obtained, 
ame Call: routsne BATTLE to obtain this current 
mPicOrmation. 

Lines 10-15 Check if battle damage has been sustained, 
print a message if damage has been incurred and end the 
meucan> without action. 

Lines 17-23 Update the current knowledge of the ammo 


Situation on the weapon systen. 
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Lines 25-61 Sequentiaily address each ammo type carried on 
a weapon system; determine a percent fill; temporarily 
amano oeeconmerol to. CHECK" (line 63) in order to 
determine the correct LON to be assigned; and assign an 
LON. 

Lines 63-89 Receive a percent value from lines 25-61 and 
match this percent to that type of weapon's LON array. 
Pass the LON value determined back to lines 25-61 for 


assignment. 


fee TROUTINE P.CLASS. V" 

Routine P.CLASS.V is called by events UP.PLT.AMMO, 
CO.RESUPPLY.ARR, and REDISTRIBUTE for each platoon played in 
the modei to update their ammunition LONsS according to the 
latest weapon LON information. Additionally, a progzran 
indicator, PFLAG, is set to provide information on the 
platoon's status. 

ARGUMENTS 
J - Argument for routine P.CLASS.V specifying the platoon 
currently updating. 
PFLAG. Platoon status indicator: 

PFLAG = 1 - indicates that the platoon is out of stock 

for an ammo type and signals the company *o update its 


ammo status. 
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PFLAG = N.PCL.VITEMS ~ indicates that the platoon has no 
need for more ammo. That is, the platoon's weapons 


have been destroyed or damaged. 





PCODE (PLATOON CODE) (2-d). Holds the pointer value for a 
platoon's PCL.V.ITEMS (PLATOON CLASS V ITEMS). 

TANK 

PELELOW(PLATOON LEVEL CF NEFD) (2-d). 


PERMANENT _ATTSIBUTES_ (REAL) 





SinE.Y 
PERMANENT ATTRIBUTES (INTEGER) 


PeecL.V.ITEMS.(NUMBER OF PLATOCN CLASS V ITEMS). Unique to a 


PLATOON. LEADER. 


Pe) 
pou 
1a 
ic 
tog 
lun 
lH 

«<3 

ty 


VARIABLES _ (INTEGER) 


[ie LOOp index. 
ECURSIVE VARIABLES (REAL) 


=p ee a se ae ee ee eee 


PCT (PERCENT). Place hclder for calculations. 


PLAT.UNIT( PLATOON UNIT). Owned by a PLATOON.LEADER. Members 


are the unit's combat vehicles(TANKs). 
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TAC1. TANK AMMUNITION CODE 1. 
[maez. TANK AMMUNITION CODE 2. 
maes. TANK AMMUNITION CODE 3. 
TACY. TANK AMMUNITION CODE 4. 
TACS. TANK AMMUNITION CODE 5. 
TAC6. TANK AMMUNITION CODE 6. 
FKILL(FIREPOWER KILL). Indicates whether a TANK has 
sustained a firepower kill during the battie. 


"0" indicates no 
m1" indicates yes 
KKILL(CATASTROPHIC KILL). Indicates whether a TANK has 


Sustained a catastrophic kiil during the battie. 


"QO" indicates no 
"7" aundicates yes 
MFKILL (MOBILITY & FIREPOWER KILL). Indicates whether a IANK 


has sustained a mobility & firepower kiil during the 


Da tie. 


"0" indicates no 
"1 indicates yes 
MKILL(MOBILITY KILL). Indicates whether 2 TANK has sustained 


@ mobility kill during the battle. 


"QO" aundicates no 
nq" indicates yes 
OHT(ON-HAND 1). Current balance of ammunition 1 on a TANK. 


OH2(ON-HAND 2). Current balance of ammunition 2 on a TANK. 


OH3 (ON-HAND 3). Current balance of ammunition 3 on a TANK. 
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OH4 (ON-HAND 4). 
OHS (ON-HAND 5). 
OH6 (ON-HAND 6). 
P. SHORT (PLATOON 


(PLATOON CLASS V ITEM). 


eype. 


PoCMBT.LOSS(PLATOON COMBAT LOSS). 


Current 


SHORTAGE). 


Guzrent balance of 
Current balance of 


balance of 


Curreat 


Unigue 


ammunition 5 on 


ammunition 4 ona TANK. 


a TANK. 


ammunition 6 on a TANK. 
Shertage of a PCL.V.ITEM 


to each platoon and ammo 


Indicates that tne loss of 


a platoon weapon system negates the need for this ammo 


type. 


PAMMO.LON(PLATCON AMMO LEVEL OF NEED). 


platoon and ammo type. 


PCURR. LOAD (PLATOON CURRENT LOAD). On-hand balance 


Unique for 


Unique for each platoon and weapon type. 


PL.3B.LOAD(PLATOON BASIC LOAD). 


(PLATOON CLASS V ITEM). 


SLOAD1 (STOWED 
SLOAD2 (STOWED 
SLOAD3 (STOWED 
SLOAD4 (STOWED 
SLOADS (STO WED 


SLOAD6 (STOWED 


LOAD 


LOAD 


LOAD 


LOAD 


LOAD 


ee 
Pie 
By 
Nis 


5). 


Optimal 
Optimal 
Optimal 
Optimal 


Optimal 


LOAD 6). optimal 


PROGRAM LISTING 





ioad 


load 


load 


load 


load 


load 


ammo 


anno 


ammgao 


ammo 


ammo 


ammo 


Optimal load for a 


type 
type 
type 
type 
type 


type 


2ach 


of ammo. 


PEL. V.L020 


1 ROUTINE P.CLASS.V GIVEN J YIELDING PFLAG 
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~j OV 
Ovwo 
tai = 


J,i ? = 1 
J TdUS 
© BaD THE NEED FOR 


, OTHERWISE 


LET PCT= PCURR.LO 
VAs 


AD(PCODE (J 
DE LOnD ( CODE (o f) 7h 


a1 

We 

73 

74 

75 

76 

77 

78 PCT GE PLTLON(I,1), 

79 LET PAMMO.LON(PCODE(J,1))=5 
80 CYCLE 

84 ALWAYS 

82 TP ECT GE PLTLON (1,2) 

83 LET PAMMO.LON(PCODE (J,I))=4 
34 CYCLE 

85 ALWAYS 

86 IP BCT GE PLTLON (153) « 

87 LET PAMMO.LON (PCODE(J,1) ) =3 
88 CYCLE 

39 ALWAYS 

90 IF PCT GE PLTLON(I,4), 

94 LET PAMMO.LON(PCODE(J,I) ) =2 
92 CYCLE 

93 ALWAYS 

94 IP PCT GE PLILON (1,5), 

95 LET PANHO .LON | CODE (J,1))=1 
96 LET PFLAG = 100 

97 ALWAYS 

98 LOOP 

99 RETURN 

100 END 


SP ESE 26S ae Re Se Se cc ee ee Se ee ae 


Lines 2-3 Define recursive variables used in the routine. 

Line 4 Prints out a message to mark the start of the 
routine. 

Line 5 Starts the outside loop over all the ammo types 
eqrried by the platoon. Loop ends on line 98. 

Lines 6-7 Zero out the platoon on-hand ammunition and basic 
load ammunition fcr the update. 

Lines 8-10 Begin the inner loop over all TANKS in the 


platoon in order to obtain the most current information 
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Means enone cacn LANK. The loop ends on line 62. 
No@cemmt ne intenmation obtained from each TANK is 
“current knowledge" from its on-hand attributes. This 
is what the TANK “knows" it has on-hand. Opposite to 
this is "perfect knowledge" from its AMMO1-AMMO6 
attributes, which is what the TANK actualiy has on-hand. 

Lines 12-57 Cycle the index over the six possible choices 
Ome chs TANK until identification or lack of 
identification of the ammo code being considered is 
made. If identification is made, the on-hand balance of 
the TANK's known load is added to the platoon balance. 
Iz the weapon system is not F-KILied the base load of 
the TANK's ammo is added to the platoon base load. Base 
load is used in determining how much should be ordered. 
Tf the weapon has been F-KILLed the weapon's base load 
is ignored. This lowers the amount of ammo the platoon 
needs to have on-hand to keep its systems full. After 
updating, control is transferred to the shortage loop, 
lines 59-60 

Lines 59-61 Provide a running update of the amnounzt of ammo 
the platoon is short as the update continues over ail 


the weapon systems in the platoon. 


171 





Meme 62 Closes the locep for a TANK, transferring control 
either to line 8 to evaluate the next TANK for this ammo 
ype or out +o complete the LON computation for the ammo 
type. 

Lines 64-73 Check for a zero base load balance in the 
platoon's ammo. Anew zero balance indicates that 
battle damage to platocn weapons has negated the need 
for further requisitioning of that type of ammo. A 
message is printed identifying the round type. Further 
reguisitions for this ammo type would not be made. 

Lines 75-76 Compute the percentage of fill(on-hand/base 
load) for an ammo type. 

Lines 78-97 Cycle the percentage over the five possible LON 
threshold values until the correct value is found and 
assigned. 

Line 98 Closes the major loop in the routine and transfers 


control back to line 5 in order to update the next ammo 


type. 


fee ROUTINE COM. AMMO" 
Routine COM.AMMO is called by events UP.COM.AMHO and 
CO.RESUPPLY.ARR for each company played in the model to 


update ammunition LONS according to the most recent platoon 
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MeieiitOrmation. An argument, NO.BATTLE, is set to indicate 
whether RES.REQs should be filed or whether 4 Simple update 
is sought. Additionally, a program indicator, CFLAG, is set 
tO provide information on the system's status. 

ARGUMENTS USED 

C - Argument of COM.AMMO (COMPANY AMMUNITION) holding the 
pointer value of the company currently updating. 

CFLAG. Company status indicator; CFLAG = N.CL.V.ITSM 
indicates that the company has no need for ammunition. 
That is, the company's weapons have been damaged or 
destroyed. 


NO.BATTLE. Indicates whether RES.REQs should be filed. 


"QO" aindicates no 


"1" indicates yes 


NOMEN (NOMENCLATURE). Specifies name of round. 


GERS) 


CCODE (COMPANY CODE) (2-d). Holds the pointer value for a 
Gempany*s CCL.V.ITEMs (COMPANY CLASS V ITEMs). 

PCODE (PLATOON CODE) (2-d). Holds the pointer value for a 
Pratoon’s PCL.V.ETEMS (PLATOON CLASS V ITEMs). 


PLATOON. LEADER 
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PEODBE({RESUPPLY CODE) (2-d). Holds the pointer value for a 
moppey nce! Ss sels v. LLeMis (SUPPLY CLASS V ITEMS). 

TSTREAM (TRIP RANDOM NUMBER STREAM) 

COMLON (2-d) (COMPANY LEVEL OF NEED). 

LOBAL VARIABLES (REAL) 

MAXTRIP(MAX TRIP). The maximum time required for a convoy to 
reach its intended destination. 

MINTRIP(MIN TRIP). The minimum time reguired for a convoy to 


meach 1-S intended destination. 


ini. ¥ 
mpecL.V.ITEMS (NUMBER OF COMPANY CLASS V ITEMS). Unique to a 
Emit. 
moon (REQUISITION). 
S4.OFF (Company S-4 OFFICER). 
COUNT. Indicates 1f a resupply requisition has been filed. 
IT - Loop index. 
PCT (PERCENT) . 
ROUTINES CALLED 


= 2D a wee 2 WE ae eee eee 


UNIT FORM.F 
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SETS 9S ED 
CO.UNIT(COMPANY UNIT). Owned by a COMPANY.COMMANDER. 
Members are the unit's PLATOON.LZADERsS. 
MyANT. LIST (COMPANY WANT LIST). Contains a listing of the 
resupply requests outstanding for the company. 
TEMPORARY ENTITIES 


Beas REQ (RESUPPLY REQUEST). 


M@eenmst. LOSS(COMPANY COMBAT LOSS). Indicates that the loss of 
a company weapon system negates the need for this ammo 
type. 

C.NUM.REQON (NUMBER OF COMPANY REQUISITIONS). Total number of 
RES.REQs submitted for an SCL.V.ITEM. 

C.SHORT (COMPANY SHORTAGE). Total rounds short for a type 
ammo. 

SrunO. LON(COMPANY AMMUNITION LEVEL OF NEED). 

CCURR. LOAD (COMPANY CURRENT LOAD). On-hand palance for an 
ammo type. 

CO.B.LOAD(COMPANY BASIC LOAD). Optimal load for am ammo 


type. 
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ISSUEE. Argument of UP.S4Y.AMMO (UPDATE.S4 .AMMUNITION) holding 
the pointer of the requesting unit. 


ISSUER. Argument of UP.SY.AMMO(UPDATE.SY.AMMUNITION) holding 


Neund 


ene pointer of the wnat supply orficer. 
PCURR. LOAD (PLATOON CURRENT LOAD). On-hand balance for an 
ammo type. 


PL.B.LOAD(PLATOON BASIC LOAD). Optimal load for an ammo 


type. 
Peer ReESUPPLY AMMO CODE). Of a RES.REQ(RESUPPLY REQUEST). 
REQUESTOR. Of a RES.REQ(RESUPPLY REQUEST). Contains the 
pointer of the unit reguesting. 
POTY(REQULRED QUANTITY). Of a RES.REG(RESUPPLY REQUEST). 


SPRIORITY (SUPPLY PRIORITY). OF a RES.REQ (RESUPPLY REQUEST). 


Pirie. OL creation of request. 


ROUTINE COM.AMMO GIVEN C,NO.BATTLE YIELDING CFLAG 
DEFINE NO.BATILE,IT,COUNT,CFLAG,AND C 

AS INTEGER VARIABLES 

DEFINE PCT AS A REAL Pe cone 

PR ieee Tie Vv AS FOLLOWS 


IP Co. B. LOAD (CCODE E(C,T)) = 
LET CFLAG = 
IF C.CMBT. LOSS (eCO DE IC, 10) |e 
LET C.CMBT.LOSS(CCODE(C,I)) = 1 


OO YDANEWNOABOWOWNN MNEWNH 


| EVENT COM. AMMO CALLED AT TIME. V 2%, cae 
FORE TOM CCl. ver ThMS (C) ,DO 
LET CCURR. LOAD (CCODE (CT) J = 0 
LET CO.B.LOAD(CCODE(C,1)) = 0 
1 FOR EVERY PLATOON LEADER IN CO.UNIT(C) , DO 
1 ADD PCURR. LOAD (PCODE (PLATOON. LEADER, 1) ) 
1 TO CCURR.LOAD(CCODE(C,1) ) 
1 ADD PL.8B. LOAD (PCODE (PLATOON. LEADER,1I) ) 
1 TO CO.B.LOAD (CCODE(C,1)) 
1 LOOP 
1 0 
1 
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bo 
© 


QI III I IDAA A AAD AAAANI NNN NNN & EEE SWWWWWWWWWWNNNYNNNNNN 
JOAUEWN ACW DIANE WN AoW! DOU E WHA OD DIDUNE WN OOD IAUNIE WHA DOM SANUS WD 


MOoMmonondond—~~ 
OWN & WN Aa OW MO 


PRINT 2 LINES WITH I, Cc THUS 
BATTLE DAMAGE HAS NEGATED THE NEED FOR 
AMMO *% IN COMPANY ¥* 


tdi<t 
Qa e 


LE 


ta © 
ty r3 
NH 
mw 
BAK HANOUWWN=s 
ro HOH Fe} 
On 


YS 
e 
rs 
T= R. LOAD (CCODE (C,I) ) 
B. (CCODE Gran) 

G ON (T Vy 

cA L (CCODE(C,1)) =5 


Kt pe 

mrt ht 
Qtr wart 
Ota'td ry OV 


HD 
Tels 


& 

(CC6DEC, 1) ) =4 
(debe {C,I) ) =3 
pa 


lan Kid 
myc 
wQtt 
Hur PIU 
ON 


COMLO 
MO.LON 
HORTAG 


IF PCT GE COMLON (I 45) ¢ 
LET CAMMO.LON (CCODE(C,1I)) =1 
ALWAYS 


‘SHORTAGE! 
LET C.SHORT (CCODE(C,I)) = CO.B.LOAD(CCODE(C,1)) 
=~ ECURR. LOAD (CCODE (C,I)) 


Oty 'O b> OLy'U 
HOR 


(ceODe(c, 1) ) =2 
& 


ar 


‘'RESUPPLY' 

1 CHECK IF RESUPPLY NEEDE 

IF CAMEO. LON (CCODE (C-1)) E 
GO TO LOOP 

OTHERWISE 


‘TF A PRIOR LON IS EQUAL TO THE CURR LON, CYCLE. 


FOR BACH RES.REQ IN CWANT.LIST (Cc) 
WITH RAC (RES. RE Te AND REQUESTO (RES. REQ) ¢ DO 
= CAMMO.LON (eee) 


D 
E 5 OR NO.BAITLE iQ 1 


IF SPRIORITY (RES «REQ) (CCODE(C, 
GO TO LOOP 
OTHERWISE 
_,1LOOP3' LOOP 
''ORDER THE AMMUNITION 
CREATE A RES, REQ CALLED RCODE(C,1I) 
{ — 
LET REQUESTOR (RCODE(C, 1) }, = C 
Let RP TR (RCO 2(C,1)) = RCODE(C,1) 
LET RQTY ( CODE ( .t) = CO.B. LOAD (CCODE (C,I) ) 
- CCURR.LOAD (CCODE (C,1)). 
LET STATUS (RCODE (C/I)) 5 Hosyt 
LET RAC (RC DE(C,1)) = I 
LET RNO EN(RCODE (C41) = NOMEN (1) . 
LET SPRIOR T¥ (RCODE(C,1)) = CAMMO.LON(CCODE(C,1I)) 
LET TIME(RCODE(C,1)) = TIME.V 
LET REQN(C) = REON(C) + 1 
LET C.NUM. BQN (CCODE (CoT)) = 
- “"C.NUM.REQN (CCODE (Cy I), F 1 
_ PILE RCODE(C,I) IN CHANT. LIST (C) 
‘LOOP 1" LOOP 
IF COUNT = 


1 
SCHEDULE A’ UP.S4.AMMO (S4.0FF(C) ,C) 
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7 PeeovercOn ie (MENT REPOMAXTREIP,TSTREaM) MINUTES 
83 ALWAYS 
89 RETURN 
3) i 23 
XPLANATION OF CODE 


Lines 2-4 Define recursive variables used in the routine. 

Line 5 Prints out a message to mark the start of the 
mont ine. 

fone 7 tarts the outside loop over all the ammo types 
ea=riea by the company. Loop ends on line 83. 

Lines 8-9 Zero out the company on-aand ammunition and basic 
load ammuniticn for the update. 

Lines 10-15 Begin an inner loop cver all platoons in the 
company in order to obtain the most current on-hand and 
base load information available in each platoon. The 
loop ends on line 15. Note: the information obtained 
from ¢ach platoon is "current knowledge", which is what 
the platoon knows it has on-hand, as opposed to "perfect 
Knowledge", which is what the platoon actualiy has 
on-hand. 

Lines 16-23 Check for a zero base load balance in the 
company's ammo. This would indicate that battle damage 
+). company weapons has negated the need for further 


requisitioning of that type of ammo. A message is 
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Peston ener eying the EOUnd type. Further requisitions 
would not be made. 

Line 24-25 Compute the percentage of filil(or-hand/base 
load) for an ammo type. 

Lines 26-45 Cycle the percentage over the five pessible LON 
threshold values until the correct value is found and 
assigned. Control is then directed to lines 47-49 to 
determine the unit shortage. 

Lines 47-49 Provide an update of the total amount of ammo 
+he company is shcert. 


Lines 51-55 Check if an initial ammo request needs to be 


th 


iled. Ammunitions with LON values equal to 5 are 
cycled. Additionally, a NO.BATTLE check is made. 
NO.BATTLE equal to 1 indicates that a simple update is 
required and no RES.REQs are to be submitted. 

Lines 57-64 Check any previous requisitions for the ammo 
type being reviewed. If the previous rtequest has a 
priority equal to the current LON there is no need for a 
new request to be filed and the routine is cycled. 

Lines 66-80 Create a requisition to be forwarded +o 
battalion supply. The attributes set in the request 


are: requestor identification; a request pointer; a 
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requested quantity; a request status; a request anmo 
code pointing to a particular ammo type; a reguest 
nomenclature; a request priority; time submitted; and 
total requests submitted for that ammo type. 

tne 81 Files the reguest in the company's want list. 

Line 83 Closes the major loop in the routine and transfers 
control to Line 7 to begin a loop over the next aanmo 
ay De. 

Lines 85-88 The variable COUNT keys the fact that a 
requisition has been created and must be forwarded to 


battalion. If appropriate, an UP.SY.AMMO is scheduled. 


meee ROUTINE BATTLE" 

Routine BATTLE is called from routine W.AMMO to obtain 
the most recent expenditure and damage information. The 
routine generates ammunition expenditures for each alive 
weapon according to designated rates of fire and 
probabilities of fire. It also randomly damages and 
destroys vehicles according to user designated probabilities 
of damage. 

ARGUMENTS USED 
A - Holds the value of the weapon system updating its 
Situation. 


DEEL TOLMEAN 
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AMMO1. AP. TOW(ARMOR PIERCING/TOW ROUNDS). 
AMMO2. HE. DRAG (HEAT/DRAGON ROUNDS). 
AMMO3. AW1.OR.MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). 


AMMOW. AW2.OR.ADM(ALTERNATE WEAPON 2 OR AIR DEFENSE 


MESSILE). 


ROF (RATE OF FIRE) (2-d). Specifies the rates of fire for the 
six weapons on board any weapon system. 
RSTREAM (RESUPPLY STREAM). 


WSTREAM (WEAPON RANDOM NUMBER STREAM). 


PeOeND {BATTLE END). Termination time of daily battle. 

PeorAn?T (BATTLE START). Start time of daily battle. 

POD (2-d) (PROBABILITY OF DAMAGE). For all weapon systems. 

POF (2-d) (PROBABILITY OF FIRE). For all weapon systems. 
BRMANENT ATTRIBUTE (REAL) 


Te ee ee SS a Se Se SS ee 2 


Penk. V 


LAMT({LAMBDA 1). Holds the value of the probability of fire 
for AMMO1 from the POF(PROBABILITY OF FIRE) array. 
Brie (LAMBDA 2). Holds the value cf the probability of fire 


moc AMMOZ from the POF(PROBAEILITY OF FIRE) array. 
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LAM3 (LAMBDA 3). Holds the value cf the probability of fire 
fOr AMMO3 E>om the POF (PROBABILITY OF FIRE) array. 
LAMY (LAMBDA 4). Holds the value of the probability of fire 
for AMMOY from the POF(PROBABILITY OF FIRE) array. 
LAM5 (LAMBDA 5). Holds the value of the probability of fire 
moanannOS trom the POr(PROBABILITY OF FIRE) array. 
LAM6 (LAMBDA 6). Holds the value of the probability of fire 
for AMMO6 from the POF (PROBABILITY OF FIRE) array. 

EXPONENTIAL.F, MAX.F, and RANDOM.F . 

SETS 

TNK.ALIVE(TANK ALIVE). Owned by the system. Members are 
vehicles still alive within the simulation. 

BeEMOS (AMMUNITION 5). Of TANK. 

AMMO6 (AMMUNITION 6). Of TANK. 

AP. TOW (ARMOR-PLIERCING/TOW) . Ammunition 1 of TANK. 

memmeron . MNSLS(ALTERNATE WEAPON 1 OR MISSILE 3). Per trare 3 
Of TANK. 

AW2.OR.ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE). 


Ammun Ttzon 4& of TANK. 
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Bet LE(FLRePOWER KILL). Indicates whether a TANK nas 
sustained a firepower kill during the battle. 


"oO" indicates no 
"7" indicates yes 
HE. DRAG (HEAI/DRAGON ROUNDS). Ammunition 2 of TANK. 


KKILL(CATASTROPHIC KILL). Indicates whether a TANK has 
sustained a catastrophic kill during the battle. 


"Oo" andicates no 
“7% indicates yes 
MFKILL (MOBILITY & FIREPOWER KILL). Indicates whether a TANK 


has sustained a mobility and firepower Kill during the 
battle 


"QO" indicates no 
"qt indicates yes 
MKILL(MOBILITY KILL). Indicates whether a TANK has sustained 


MenODLLIey K1L) during the battle. 


"Ot indicates no 
"7" indicates yes 
POINTER. Machine address of TANK. 


MeNo iY PE(WEAPON TYPE). Of TANK. 


PROGRAM LISTING 

1 ROUTINE BATTLE (A) 

2 DEFINE A AS AN INTEGER VARIABLE 

3 DEFINE LAM1,LAM2,LAM3,LAL 

4 LAM5, AND LAM6 AS’ REAL VARLABLES 

6 (1 CHECK IF BATTLE IN PROGRESS, IF NOT, RETURN 

7 PRINT 1 LINE WITH £.START AND 3. END AS FOLLOWS 

BSTART = 2% | ee kx BLEND = *%, 

8 IF TIME.V LT B. a START OR TIME.V GT B.END, RETURN 
2 OTHERWISE 
11  "' ESTABLISH RATE OF FIRE FOR EACH AMMUNITION FIRED. 
12 LET LAM? = ROF (WPN.TYPE (A) , 1) 
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Define recursive variables used in the 


Lines 2-4 





Lines 6-9 Check if a battle is currently in progress, if 
ieee alses the rOouLine tO return without action. 
Lines 11-17 Assign a rate of fire by weapon and ammunition 

type for the six ammo types carried by the weapon 
Wediecmung. mates Of fire are obtained from a rate of fire 
acray input by the user. 

Lines 19-43 Establish ammo expenditures for each of the six 
ammo types carried by a weapon system. Use of the weapon 
during the time period is established by comparing a 
random number to a probability of fire for the weapon 
system. Expenditure of ammo is then computed through the 
use of an exponential function using the weapon's rate 
of fire as lambda. 

Lines 45-71 Determine if battle damage has been sustained 
during the time period. Evaluation is made by comparing 
a random number against the various types of kill 


possible. 


fee ROUTINE UP.DATE" 

Routine UP.DATE is called from event B.UP.DATE and is 
used *O print a battle summary listing weapon and unit 
assets, aS well as supply status. 


GLOBAL VARIABLES _ (INTEGER) 


Utes) 





CCL.V. ITEM (COMPANY CLASS V ITEM). 

COMPANY.COMMANDER 

CONVOY 

CNUM(COMPANY NUMBER). Specifies the number of 
COMPANY.COMMANDERS created. 

fers vy. LTEM (PLATOON CLASS V ITEM). 

PLATOON. LEADER 

PNUM(PLATOON NUMBER). 

PmeoeREQ. (RESUPPLY REQUEST). 

fee ys LT EN. (SUPPLY CLASS V ITEM). 

SNUM{NUMBER OF SUPPLY OFFICERS). 

SUPPLY.OFFICER 


T.CGO(TRUCK CARGO). 


TANK 
PERMANENT ATTRIBUTES 
monn. V¥ 
RECURSIVE VARIABLES 
imo, K - Loop indicies. 
SETS 
CARGO 


CO.AMMO (COMPANY AMMUNITION). Owned Dy a COMPANY. COMMANDER. 
Members are the unit's CCL.V.ITEMS (COMPANY CLASS V 


ITEMS) . 
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meANT. LIST (COMPANY WANT LIST). 

PLAT.UNIT( PLATOON UNIT). Owned by a PLATOON. LEADER. Members 
are the unit's combat vehicles (TANKS). 

PLT.AMMO (PLATOON AMMUNITION). Owned by a PLATOON.LEADER. 
Members are the unit's PCL.V.ITEMS (PLATOON CLASS V 
frets) > 

S.AMMO (SUPPLY AMMUNITION). Owned by a SUPPLY.OFFICER. 
Members are the unit's SCL.V.ITEMS (SUPPLY CLASS V 
£TEEMS). 

Seon i’T({SOPPLY UNIT). Owned by a SUPPLY.OFFICER. Members are 
the unit's supply vehicles (TANKs). 

SCONVOY (SUPPLY CONVOY). 

SeeQN.LIST(SUPPLY REQUISITION LIST). 

SHANT.LIST (SUPPLY WANT LIST). Owned by a SUPPLY.OFFICER. 
Members are RES.REQS (RESUPPLY REQUESTS) from the combat 
Units. 


TNK.ALIVE(TANK ALIVE). 


1 ROUTINE UP. DATE. 

2 DEFINE I,J,AND K AS INTEGER VARIABLES 

3 PRINT 3 tt fiES WwETH TIME.V AS FOLLOWS 
ROUTINE UP.DATE CALLED AT #%, smh 

u ¢? 


ele one Ar CREBUTES OF EACH COMPANY .COMMANDER 
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FOR 3 = 1 TO CNUOM, DO 
EES en tontoues Cf BACH CCL.V.ITEM IN NTILLST (34 
Post eweineemobes OF BACH RES~REO IN CWANT.LIST (J 
490° 
LIST ATTRIBUTES OF EVERY PLATOON.LEADER 
EOR = 1 TO PNUM, DO 
Peo a Ree ico Ones aAGH PCLL.V. ITEM TN PLT.AMMO (TZ) 
Pest Alo nheout ss OF EACH TANK IN PLAT.UNIT (T) 
LOOE 
Heo ea lant oud poem BVveEnY SUPPLY.OFPICER 
FOR K = 1 T0 SNUM, DO 


LIST ATTRIBUTES OF EACH SCL.V.ITEM IN S AWUHO (K 
LIST ATTRIBUTES OF EACH RES.REQ IN SWANT.LIS | ) 
LIST ATTRIBUTES OF EACH RES.REQ IN SKEQN.LIST(K) 
LIST ATTRIBUTES OF EACH CONVOY IN SCONVOY(K) 
LIST ATTRIBUTES OF EACH TANK IN S.UNiT (K) 


1908 
FOR EACH TANK IN TNK.ALIVE 

WITH SYS. TYPE (TANK) _2Q 7D 

tubs? ATTRIBUTES OF Each T.CGO IN CARGO (TANK) 


aAOODOTAIE WN 2 O19 OAYNDN FW OW ONO 


WI QJ RODIDOD AOD AIDA DO AD at ed et et ad ed ed 2 


Gd 
WIh 


Line 2 Defines recursive variables for the routine. 

Line 3 Prints a message marking the start of the routine 

Lines 5-9 Mark a loop over the attributes and sets 
belonging to each company commander. 

Line 5 Lists attributes of each company commander. 

Line 7 Lists attributes of each class V item the company 
commnander owns. 

Line 8 Lists attributes of each resupply request the 
company commander has cutstanding. 

Lines 11-15 Mark a loop over the attributes and sets 
belonging to each platoon leader. 


Line 11 Lists attributes of each PLATOON.LEADER. 
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Line 13 Lists the the attributes of each class V item tha 
platocn leader owns. 

Line 14 Lists the attributes of each weapon system of the 
unit. 

Lines 17-24 Mark a loop over the attriputes and sets 
belonging to each supply officer. 

Line 17 Lists the attributes of each supply officer 

Line 19 Lists the attributes of each ciass V iten 

Line 20 Lists the attributes of outstanding requests fron 
Supported companies. 

Line 21 Lists the attributes of outstanding requests sent 
to the ATP/ASP. 

Line 22 Lists the attributes of each convoy the supply unit 
owns. 

Line 23 Lists the attributes of all supply vehicles in the 
mina t 

Lines 26-29 Mark a lcop over all resupply vehicles, listing 


the attributes of all supply cargo carried. 


ree ROUTINE FILE. UP. DATE" 


This routine is called from event UP.S4.AMMO. It is 


used =o update the S-4&'s out standing request list by filing 
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new requests by priority and eliminating dupiicate older 
requests of lesser priority. 
A - Points to supply officer updating. 


COM. Points *o company currently updating. 


meeps (SUPPLY CODE) (2-d). HOLD'S POINTER FOR SCL.V.ITEMS. 


NEW. REQ (NEW REQUISITION). 
OLD.REQ(OLD REQUISITION). 
ROUTINES CALLED 
FILE.UPDATE 
SETS USED 
CWANT. LIST (COMPANY WANT LIST). 
Swent. LIST (SUPPLY WANT LIST). 
BarAND. for SCL.V.ITEM. 
M.C.CGO. LIST (MEMBER CONVOY CARGO LIST). System generated 


Variable indicating whether or not a resupply request is 


Sona convoy cargo list. 
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Pareroure LY AMMUNETLON CODE). Ateribute of an SCL.V.ITEM 
which points to a specific ammo type carried by the 
supply unit 

REQUESTOR. Attribute of a RES.REQ pointing to the requesting 
wat } 

ROTY(RESUPPLY QUANTITY). Attribute of a RES.REQ holding the 
total quantity requested by a unit. 

PerrORITY(SUPPLY PRIORITY). Attribute of a RES.REC 
specifying the urgency of need for the ammo request. 

TEMPORARY At 


RNOMEN (RESUPPLY NOMENCLATURE). Attribute of a RES.REQ 
specifying the reguested ammo's nomenclature. 
TEMPORARY ENTITY 
feoeroQ (RESUPPLY REQUEST). 
eevee lL TEM (SUPPLY CLASS V¥V ITEM). Holds information for a 


Supply unit about a particular ammo type used by the 


unit. Belongs to the set S.AMMO. 





Pewee’. Sinulation time. 


ROUTINE FILE. UPDATE (A, COW) 
DEFINE A,COM, OLD. REQ,NSW.REQ AS INTEGER VARIABLES 
ee Mo eeneereeueok CURRENTLY BEING RECEIVED 
AND CAPTURE DEMAND DATA 
Presit cane atte TIME. VY THUS 
if LLED AT TIME.V = 7 Sore 


NH UOEWN- 
i 
en 





8 IF NEW.REQ IS NOT IN SOME SWANT.LIST 
9 LET DEMAND (SCODE (A, RAC NEW. REQ) ) ) = 
19 aL qe MAND (SCODE (A, AC (NEW.REQ))) + ROTY (NEW. REQ) 
2 FOR ALL OLD.REQ IN SWANT.LIST A) 
13 WITH RNOMEN(CLD.REQ) = RNOMEN (NEW. REQ) 
14 Mine GeeGO. List (OLD. REO) = 0 
15 AND REQUESTOR (OLD. REQ) = REQUESTOR (NEW. REQ) , DO 
16 IF SPRIORITY (OLD.REQ) NE SPRIORITY (NEW.REQ) , 
vi LET DEMAND (SCODE (A,RAC (NEW. REQ) )) 
18 Ee ae 2 (A/RAC (OLD. 22Q)) ) 
19 # ROTY(NEW. REQ) - ROTY (OLD.REQ) 
20 REMOVE OLD.REQ FROM SHANE. LIS? (a) 
D1 REMOVE CLD.REO FROM CWANT. LIST (COM) 
22 DESTROY RES.REQ CALLED OLD.REQO 
23 ALWAYS 
24 LOOP 
25 Tr NEW-REQ IS NOT IN SOME SWANT.LIST, 
26 FILE NEW. REQ IN SWANT.LIST(A) 
27 ALWAYS 
28 LOOP 
29 RETURN 
31 END 


Line 2 Defines the recursive variables used in the routine. 

Line 5 Prints a message marking the beginning of the event. 

Lines 6-7 Begin the major outer loop for the routine by 
looping over all outstanding requests that have not been 
loaded on a resupply truck. Loop ends on line 28. 

Lines 8-11 Determine if the request has been filed 
previously with the S-4. If not it is treated as new and 
its full demand data is captured. 

Lines 12-25 Begin an inner loop which determines if a 
Similar request for the type of ammo in the outer loop 
has been filed previously with the S-4. If so, a 
comparison is made between request priority values. If 


the values are the same, this indicates that the new 
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request has been filed previcusly and no further action 
53 necessary. If the priorities are different, this 
mndicates that the unit is inereasing its urgency of 
need for the ammo. The new request is filed and the oid 
one is destroyed. The difference between the new and 
old values is added to the demand. Loop ends on line 
24. 

meee 24 Closes the inner loop for the routine. Control is 
Bearsrerred back to liane 12 to continue comparing 
reguests or out to the next new request. 

Lines 25-27 File all genuinely new requests in the S-4's 
Mant list. 

Line 28 Closes the main routine loop begun on line 8. 


Control is transferred back to the next reguest or out. 


moe "ROUTINE LOAD.THE.TRUCKS" 

This routine is called from event UP.S4.AMMO. It is 
used to load supply cargo onto individual trucks. [In 
execution, the event checks the number of trucks allocated 
to carry a specific supply request and loads the number of 
trucks specified subject to the weight and cube limitations 
of the truck. 

ARGUMENT (INTEGER) 


A - Pointer value to the S-4 officer. 


133 





mon. 2D (CONVOY ID). Holds the pointer value of the convoy 
eucrentily being filled. 

N.RNDS (NUMBER OF ROUNDS). 

RR(RESUPPLY REQUEST). Holds the pointer of the resupply 
request being currently filled. 

ARGUMENT (REAL) 

CU.REQ (CUBE REQUIRED). Holds the total cube that is required 
in order to ship a resupply request. 

WT.REQ (WEIGHT REQUIRED). Holds the total weight that is 
required in order to ship a resupply request. 


LOBAL VARIABLE (INTEGER) 


aS SS [= 





RES.REQ (RESUPPLY REQUEST). 

SeOUE (SUPPLY CODE). 

TANK 

RC. TEMP (ROUND/CUBE TEMPORARY). Holds the computational value 
of the number of rounds that may be loaded on a truck 
due to cube restrictions. 

RNDS(ROUNDS). Holds the number cf reunds being released to 
fill a request. 

RW.TEMP (ROUND/WEIGHT TEMPORARY). Holds the computational 
value of the number of rounds that may be loaded ona 


<ruck due to weignt restrictions. 
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T.COUNT (TRUCK COUNT). Holds the value of the rumber of 


trucks already loaded for a particular resupply request. 


meeo.e THE.T RUCK, MIN.F, TRUNC.F 
SETS _USED 
CARGO. Contains a listing of the T.CGO loaded on a 
particular truck. 
ELEMENTS. Set of trucks owned by a CONVOY. 
S.UNIT(SUPPLY UNIT). Contains the unit's supply 
vehicles (TANKS). 
TEMPORARY ATTRIBUTES (ALPHA) 
RNOMEN (RESUPPLY NOMENCLATURE). Attribute of an SCL.V.ITEM 
containing the name of the particular ammo type. 
TNOMEN (TRUCK NOMENCLATURE). Contains the name of a 
particular ammo type. 
FAILL(FIREPOWER KILL). 
Poet L (CATASTROPHIC KILL). 
M.ELEMENTS. Specifies membership in a CONVOY. 
BERILL (MOBILITY AND FIREPOWER KILL). 


~N 


MeeoL {MOBILITY KILL). 
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N.CARGO(NUMBER IN CARGO). Indicates the total number of 
T.CGO items loaded on a particular truck. 

N.ELEMENTS (NUMBER OF Z£LEMENTS). Ih a convoy. 

mere ALLOC(NUMBER OF TRUCKS ALLOCATED). Contains the number 


of +rucks to be allocated to nove the rounds released 


th 


925 a resupodly request. 

ONHAND. Holds the on-hand balance for rounds of a particular 
type at the resuprly point. 

POINTER. Of a TANK. 

REC (RESUPPLY AMMUNITION CODE). Attribute of an SCL.V.ITEM 
which points to a specific ammo type carried by the 
Supply unit. 

RDS.PKG (ROUNDS PACKAGE). Attribute of a SCL.V.ITEM 
specifying the number of rounds on an ammo pallet. 
Peeeon (RESUPPLY FILL). Attribute of a RES.REQ specifying tne 

amount of ammunition released to fill a request. 

B@rY {RESUPPLY QUANTITY). Attribute of a RES.REQ holding the 
total quantity reguested by a unit. 

mee nt R (RESUPPLY REQUEST POINTER). 

SPACE. Attribute of a CONVOY holding the amount of Loading 


space available on trucks in the convoy. 
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PEv(TRUCK CUBE) . The cube that a truck has available to be 
mot ied. 

TPNTR(TRUCK POINTER). 

TOTY(TRUCK QUANTITY). Holds the number of rounds within a 
He ©cGO that are loaded on a truck. 

meee (TRUCK AMMUNITION CODE). Of a T.CGO iten. 

TWE (TRUCK WEIGHT). The weight that a truck has available to 


be filled. 


CU. PKG (CUBE PACKAGE) Attribute of a SCL.V.ITEMN specifying 
the cube of an ammunition pallet. 
AT.PKG (WEIGHT PACKAGE). Attribute of a SCL.V.ITEM specifying 
the weight of a pallet of the ammo being considered. 
TEMPORARY ENTITY 


T.CGO. Supplies carried on a resupply vehicle (TANK). 


PROGRAM LISTING 


1 ROUTINE LOAD. THE. TRUCKS 
2 (A pRR WT REQ, CU. REO, N.RNDS, CON ID) 
3 DEFINE ENDS CON. 312 COUNT, RW.TEMP, 
4 TEMP AeND TREGE Whar LES 
5 REPTNE aT. REO. maui REO PCT AS SEAL VARIABLES 
6 PRINT 1 LINE THUS 
ROUTINE LOAD THE TRUCKS CALLED 
7 LET T.COUNT = 0 
8 FOR EVERY TANK IN S.UNIT(A) 
9 WITH M.ELEMENTS(TANK) EQ 
10 AND SKILL (TANK) EQ 0 AND FKILL (TANK) EQ 0 
11. AND MPKILL (TAN ) EQ O AND KKILL(TANK) =£Q 0, DO 
12 '*LOOD CHECK 
13 LET T.COUNT = T.COUNT 
14 IF T.COUNT GT NL Te ALLOC (RES. REQ) OR WI.REO LE 0 
15 OR CU.REQ LE 0 OR N.RNDS LE 
16 LEAVE 
17 OTHERWISE 
13 't CHECK IF ITEMS EXCEED THE TRUCK'S CAPACITY 
19 't IP SO, ADJUST 


ey 





TE Ww kee GT Lt ( 
LET RW.TEMP = TW 


Bet 


LET RC.TEMP = T 
LET RNDS = MIN 

LET N.RNDS = N 
LET RNDS = N.RN 

SPACE (CON.I 
TANK) 

EN (BES . .REQ) 


ba all 
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LOOP 
RETURN 
END 


EXPLANATION OF CODE 
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Lines 3-5 Define recursive variables used in the routine. 

Line 6 Prints a message indicating that the routine has 
been called. 

Lines 8-11 Begin the major loop for the routine to assign 
the resupply mission to vehicles in the supply unit that 
have not previously sustained damage or been assigned to 


@ convoy. Loop ends on line 62. 
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menes 12-17 Check the loop for completion through the 
assignment of all trucks allocated to the mission, or 
through the completion of the loading process. 

Lines 18-32 Check if the request exceeds the carrying 
capacity of the truck being loaded. If so, the amount 
being loaded is adjusted to the maximum load for that 
meuck. 

Line 33 Creates a TRUCK.CARGO to hold information as to the 
type and quantity of ammo to be loadéd on a truck. 

Line 34 Captures the pointer value of the truck the cargo 
is leaded on. 

Line 35 Captures the pointer value of the resupply request 
being filled. 

Line 36 Captures the nomenclature of the regquest being 
filled. 

Line 37 Captures the ammunition code of the request being 
el. led 

Line 38 Captures the guantity being loaded on the truck. 

Meme) 39 Files the cargo on the last truck in the convoy. 

Line 41 Reduces the number of rounds yet to be filled for 


the request 
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Line 42 Adds the quantity released to the fill attribute of 
the request. 

Line 43 Reduces the required quantity for the resupply 
request. 

Lines 44-46 Reduce the on-hand stocks for the ammo type at 
ev= supply point. 

Lines 47-53 Reduce the weight and cube reguired to fill the 
request. 

Lines 54-60 Reduce the weight and cube available on the 
eeuck tO fill requests. 

Line 61 Files tne truck in the active convoy. 

Line 62 Closes the major routine loop begun on line 8. 
Control is either transferred back to fil11 another truck 


with the same cargo or transferred out. 


eee ROUTINE WT.AND.CU" 
This routine is called by event UP.S4Y.AMMO and is used 
to compute the total weight and cube capacity present at 


battalion which can be used to carry supplies. 


Va SS ==] SS SS 


206 





CU(CUBE). Holds the maximum cube that may be ioaded on a 
resupply vehicle. 

BO,AVALL (CUBE AVAILABLs). Holds the total cube capacity that 
is available within the supply unit for the shipment of 
Supplies. 

TRKS.AVAIL (TRUCKS. AVAILABLE). Holds the total number of 
trucks available for assignment to a resupply mission at 
any time. 

WIE (WEIGHT). Holds the maximum weight that may be loaded on a 
resupoly vehicle. 

WE. AVAIL(WEIGHT AVAILABLE). Holds the total weight capacity 
that is available within the supply unit for the 


shipment of supplies. 


oP) 


LOBAL_VARIABLE (INTEGER) 


TANK 


72) 


SET 


SesUNTT (SUPPLY UNIT). Contains the unit's supply 


v2hicles(TANKs). 


PRELL(PIREPOWER KILL). 
KKILL(CATASTROPHIC KILL). 
Me-ELEMENTS. Specifies membership in a CONVOY. 


MAX.CUBE (MAXIMUM CUBE). 
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MAX. WI (MAXIMUM WEIGHT). 
MFKILL(MOBILITY AND FIREPOWER KILL). 
MKILL(MOBILITY KILL). 
WI(WEIGHT). Holds «he maximum weight that may be loaded on a 
resupply vehicle 
ROUTINE CALLED 
me. AND.CUBE 
PROGRAM LISTING 


ROUTINE WT.ANCD.CUBE GIVEN A 


YIELDING WI. AVAIL,CU.AVAIL,TEKKS .AVAIL,WT,CU 
DEFINE WT.AVAIL,CU.AVAITL,WT,CU AS REAL VARIABLES 
DEFINE TRKS.AVAIL,A AS INTEGER VARIABLES 


Phen oe! LEE THUS 
ROUTINE WT.AND. CUBE CALLED 


ie DETERMINE THE WT.AND ae AVAIL FOR SHIPPING 


(O00 WOU WN tO OO NS WN = 
H = 
= 
O 
He 4 
A 
i, 
t+ 
t- 


FOR EVERY TANK IN S.UNIT(A 
WITH M.ELEMENTS(TANK) EQ 0 
1 (TANK), BQ OQ AND FKILL(TANK) FQ 0 
11 AND MFKILL(TANK) EQ O AND KKILL (TANK) FQ 0, DO 
1 LET WT.AVAIL = WT.AVAIL + WAX. AT (T NX) 
1 LET CU.AVAIL = CU.AVAIL + MAX. CUBE (TANK) 
1 Let TRKS.AVAIL = TRKS.AVAIL + 1 
: LET WT = WAX. WI (TANK) 
1 LET CU = MAX.CUBE (TANK) 
: 


it 


XPLANATION OF _CODE 

Lines 3-4 Define recursive variables used in the routine 

Line 5 Prints a message indicating that the routine has 
been called. 

memes 8-17 Begin the major loop for the routine, looping 
over all available cargo carriers, summing the total 


weight and cube available for shipment, determining a 
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total number of trucks available, and determining the 


max weight and max cube available on any one truck. 


fee ROUTINE PRI.RESUPPLY" 

This routine is called by event UP.S4Y.AMMO and is used 
moeraetermine an optimum fill for priority 1 and 2 
Beaqdisitions. In execution, the routine seeks to fill all 
Beeorlt-~y 2 requesitions to a minimum percentage of fill for 
all requests by: first, setting multipliers to reduce 
priority 2 fill; second, re-evaluating the overall fill of 
Pae@Or.=y 2 requests; and third, if necessary, reducing fill 
On priority 1 requests to open more Space for priority 2 


requests. 


A - Points to the S-4 currently updating. 

LON1. Variable which indicates whether Level of Need 1 
requests are currently filed with the supply officer. 

LON2. Variable which indicates whether Level of Need 2 
requests are currently filed with the supply officer. 

CU.AVAIL (CUBE AVAILABLE). Holds the total cube capacity that 
1S available within the supply unit for the shipment of 


Supplies. 
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Poel (MULTEPLEER 1). Gelds the multiplier for LON 1 requests 
which is used to reduce the fill on such requests. 

MUL2 (MULTIPLIER 2). Holds the multiplier for LON 2 requests 
which is used to reduce the fiil on such requests. 
WE.AVAIL(WEIGHT AVAILABLE). Holds the total weight capacity 
that is available within the supply unit for the 

Shipment of supplies. 
GLOBAL VARIABLES (INTEGER) 


moose ROO (RESUPPLY REQUEST). 


BEODE (SUPPLY CODE). 


C.LIPCT (CRITICAL LON1 PERCENTAGE). Holds the maxinun 
percentage that LON1 requisitions may be reduced to in 
order to release space on a convoy for other critical 
LON1 and LON2 requests. 

C.L2CU (CRITICAL LON2 CUBE). Holds the maximum percent of 
eabe that LON2 requisitions may be cut to in order to 
release space on a convoy for other critical LON1 and 
LON2 requisitions. 

C.L2WT (CRITICAL LON2 WEIGHT). Holds the maximum percant of 
weight that LON2 requisitions may be cut to in order to 
release space on a convoy for other critical LON1 and 


MONZ requisitions. 
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CU.SHIP(CUBE OF SHIPMENT). Combined total cube of current 
LON1 and LON2 requests. 

C1. Holds the total cube of current LON1 requests. 

CiPpcT. Percent of LON1 requests which can be filled if all 
LON2 requests are filled to a minimum based on cube. 

C2. Holds the total cube of current LON2 reguests. 

C2PCT. Percent of LON2 requests which can be filled if all 
LON1 requests are filled based on cube. 

WT.SHIP(WEIGHT OF SHIPMENT). Combined total weight of 
current LON? and LON2 requests. 

W1. Holds tne total weight of current LON1 requests. 

WIPCT. Percent of LON1 requests which can pe filied if all 
LON2 requests are filled to a minimum based on weight. 

W2. Holds the total weight of current LON2 requests. 

W2PCT. Percent of LON2 requests which can be filled if ail 


LON1 requests are filled based on weight. 


8) 


OUTINES 


| 





Meee, MIN.F, PRI. RESUPPLY 


7) 


ET 


SWANT.LIST (SUPPLY WANT LIST). 
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RAC(RSSUPPLY AMMUNITION CODE). Attribute of an SCL.V.ITEM 
which points to a specific ammo type carried by the 
Supply unit. 

RDS.PKG(ROUNDS PACKAGE). Attribute of a SCL.V.ITEM 
Specifying the number of roundS on an ammo pallec. 
Meera eSUPPLY QUANTITY). Attribute of a RES.REQ holding the 

total quantity reguested by a unit. 

SPRIORITY (SUPPLY PRIORITY). Attribute of a RES.REQ 
specifying she urgency of need for the ammo request. 

TEMPORARY ATTRIBUTE _ (REAL) 

CU.PKG (CUBE PACKAGE). Attribute of a SCL.V.ITEM specifying 

the cuhe of an ammunition pallet. 


WI.PKG (WEIGHT PACKAGE). Attribute of a SCL.V.ITEM specifying 


the weight of an ammunition pallet. 


1 ROUTINE PRI.RESUPPLY GIVEN WT.AVAIL,CU.AVAIL,A 
2 YIELDING MUL1,MUL2,LON1, LON2 
3 DEFINE A,LON1,LON2 AS INTEGER VARIABLES 
4 DEFINE Wi,¥2,C1,C2,WT. SHIP ,CU.SHIP,MUL1,MUL2, 
5 aT AVAIL, CO AVALL, G22 CT, ober: wW1PC®,CIPCT 
6 AS REAL VARIABLES 
7 PRINT 1 LINE THUS 

ROUTINE PRI.RESUPPLY CALLED 
8 tt DETERMINE WEIGHT AND CUBE REQUIRED 
9 '' FOR LON1 & LON2 MISSIONS 
10 FOR EVERY RES. REQ IN SWANT. LIST (A) 
1} WITH SPRIORITY (RES REQ) =2 
12 OR SPRIORITY (RES .REQ) | 2D O 
13 GO TO L1,L2 PER SPRIORITY (RES. REQ) 
14 ‘Li? LET’ wt = wi + WT BRC (SCODz (2, RAC (RES. REQ))) 
15 *ROTY (RES. R 0 
16 LEDS PKG (SCODE (A, RAC (RES - R50) ) ) 
17 LET C1 = C1 + CU.PKG (SCODE (A, RAC (RES. REQ) ) 
19 PRBS. BRGLSCORE(A RAC (RES. REQ) )) 

POKGISE , RES.RE 

20 LET LON1 = 1 ( ( 
21 CYCLE 
22 £2? LET W2 = W2 + WI.PKG(SCODE(A, RAC (RES. REQ))) 
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23 #ROTY (RES. REQ) 
24 {RDS ERG (SCODE (A RAC (RES. REQ) ) ) 
25 LET C2 = C2 + WT.PKG(S ODE (A RAC (RES. REQ) } 
26 ROTY (RES . REQ) /RDS «PKG (5 OBE (A, RAC (RES. REQ) )) 
27 LET LONZ = 1 
28 LOOP 
29 LET WI.SHIP = WE.SHIP + W1 + W2 
30 LET CU.SHIP = CU.SHIP + C2 + C2 
32 **pETER IF THE MIN % OF LON 2 ITEMS ARE SHIPPED. 
33 IF (WT.SHIP GT WE.AVAIL OR CU.SHIP GT CU.AVAIL) 
34 AND LON2 EQ 1 
35 LET W2PCT = (WT.AVAIL-W1) /W2 
36 BT C2pcT = (cU.AVALL-C1) /C2 
a7 ('2EDUCE THE FILL ON LON2 REQUIREMENTS 
38 LET MUL2 = (WIN. F(W2PCT, C2PCT, 1.0) ) 
39 LET MUL1 = 1.0 
41 '*REDUCE LON1 FILL TO ALLOW MORE SPACE 
42 IF W2PCT LT C.L2WT OR C2PCT LT C.L2cU 
43 AND LON1 EQ 1 
nar LET W1PCT = WE. AVAIL“W26C-L2NT) /W 1 
45 LET CipcT = (CU.AVAIL-C2*C. L2cU) 7c1 
46 LET MUL1 = (MAX. F(W1PCT,C1PCT,C.LIPCT)) 
47 LET MUL2 = (MIN. F{(C.L2WT,C.L2CU, 1.0) ) 
48 ALWAYS 
4u9 ALWAYS 
50 RETURN 
51 END 
EXPLANATION OF CODE 
Line 3-6 Define recursive variables used in the routine. 


Line 7 Prints a message Marking the beginning of the 


Bovoin e. 

Lines 10-12 Begin the major loop of the routine 
over all resupply requests in the S-4's want 
identify the priority 1 and 2 requests. Loop 
mone 28. 

Line 13 Transfers control based on the priority 


request. 


looping 
list and 


ends on 


of the 


Lines 14-16 Sum the total weight of all priority 1 


requests. 


Lines 17-19 Sum the total cube of all priority 1 
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Line 20 Indicates the presence of an LONI] request. 

Line 21 Cycles to next request. 

menes 22-24 Sum the total weight of ail priority 2 
requests. 

Mepes 25-26 Sum the total cube of all priority 2 requests. 

Line 27 Indicates the presence of an LON2 request. 

Line 28 Ends the major loop begun on line 10. Transfer of 
control is either to the next request or out. 

Lines 29-30 Calculate the total weight and cube of 
outstanding requests due to priority 1 and 2 requests. 

Lines 32-39 Determine if all priority 2 requests have been 
filled. If not, it establishes a multiplier, Mul2, to 
reduce fiil on pricrity 2 requests in order to open up 
Space on trucks to fill a greater number of LON2 
requests. The IP check ends on line 49. 

Lines 41-48 Check again to see if all LON2 requests have at 
least been partially filled. If not, 1t establishes a 
Mita pa2ter, MULT, to reduce the fill of priority 1 
requests to open up space on trucks until the priority 2 
requests have been filled. Priority 1 requests will be 
reduced only to the percentage necessary to fill 
priority 2 requests, or to a user désignated critical 


PEiOrzty Of fill whichever comes first. 
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Gaeee EVENT BAT. L.TIME" 

Event BAT.L.TIME is initially scheduied in the main 
program and subsequently reschedules itself each day of the 
Simulation. The event is used to start and end a battle and 
to schedule moves. 


MOVE 

CNUM(COMPANY NUMBER). Specifies the number of 
COMPANY.COMMANDERS created. 

RSTREAM (RESUPPLY RANDOM NUMBER STREAM). 


WSTREAM (WEAPON RANDOM NUMBER STREAM). 


B.END(BATTLE END). Termination time of daily battle. 


BeoOcART (BATTLE START). Start time cf daily battle. 


TIME.V 


MARCH.ORDER. Argument for the event move holding the poinczer 


of the company receiving orders to move. 


Pe) 
bey 
O 
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RANDOM.F, TRUNC.F, and UNIFORM.F 


ROGRAM LISTING 


} EVENT BAT.L. TINS 
3 DEFINE I AS AN INTEGER VARIABLE 
% PRINT 1 LINE WITH TIME.V THUS ? 
; | EVENT BAT.L.TIME CALLED AT TINE.V = *.#### 
6 LET B.START = TRUNC. F(TIME. V) 
+UNIFORM.F(0.0,1.00, WSTREAM) 
7 LET BLEND = 8.START +. 25 
8 IF B.END LT? TRUONG. P(TIHE.V) + ioe 
12 pp RESCHEDULE A BAT.L.TIME AT TRUNC. 2 (TIME.V) +1.0 
11 RESCHEDULE A BAT.L.TIME AT B.END 
12 ALWAYS 
13 FOR I = 1 TO CNUM, DO 
14 IF RANDON. F (RSTREAM) LT .8 
15 SCHEDULE A MOVE(I) AT BEND + .1 
16 PRINT 3 LINES WITH I THUS 
CLPETOCTOLUr errr; iertiges! 
MOVE SCHEDULED FOR COMPANY * 
CCUCUPP eer ee eeen era rengrens 
iG ALWAYS 
18 LOOP 
19 RETURN 
20 END 
EXPLANATION OF CODE 


Line 3 Defines the recursive variable used in the routine. 

Line 4 Prints a mesSage marking the start of the routine. 

Line 6 Randomly picks a battle start time over the 24 hour 
period. 

Line 7 Schedules a battle stop time 6 hours later. 

Lines 8-12 Reschedule the battle for the next day. 

Lines 13-18 Randomly select a company to move at the end of 
a day's battle(evernt MOVE). Priat a message identifying 


the unit. 
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Eee SVENT MOVE" 


Event MOVE is scheduled in event BAT.L.TIME. The event 
only takes place after a battle and is used solely to 
schedule and 2xercise the redistribution logic. 

ARGUMENTS 
MARCH. ORDER. Argument for event MOVE hoiding the pointer of 


“h2 company receiving orders to move. 


QQ 


LOBAL VARIABLE (INTEGER) 


PLATOON. LEADER 


” 
Ir3 


CO.UNIT(COMPANY UNIT). 


C - Holds the value of the company currently moving. 
DISTR(DISTRIBUTOR). Argument for event REDISTRIBUTE holding 
the value of the unit's PLATOON.LEADER. 


EVENT SCHEDULED 





Pep torTRIBUTE 


PROGRAM LISTING 


1 UPON MOVE(C) 

2 NORMALLY HODE IS INTEGER 

3 FOR EVERY PLATOON. LEADER IN PLAT.UNIT(C), DO 
4 oS gH EDULE A REDISTRIBUTE(PLATOON.LEADER) NOW 
6 RETURN 

7 END 


EXPLANATION OF CODE 


Line 2 Defines the mode as integer. 
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Lines 3-5 Schedule a wove for each platoon in the company. 


fee "PSEVENT CO.RESUPPLY.ARR" 

Event CO.RESUPPLY.ARR is scheduled from event 
UP.S4.AMMO. The event distributes the ammunition assets 
received by a company to subordinate platoons according to 
“heir most recent LON. It then sends the RSV/convoy back to 
the battalion trains aiter an appropriate time delay 
Simulating a delivery from the ATP/ASP. 

ARGUMENT 
CNVY (CONVOY). Argument of CO.RESUPPLY.ARR(COMPANY RESUPPLY 

ARRIVE) carrying the pointer or the convey arriving. 
CO.CNVY (COMPANY CONVOY). Argument of the event 

CO.RESUPPLY.ARR (COMPANY RESUPPLY ARRIVE) holding the 

pointer value for the convoy arriving in the area. 

DEFINE TO MEAN 
AMMO1. AP.TOW(ARMOR PIERCING/TOW ROUNDS). 
AMMO2. HE.DRAG(HEAT/SDRAGON ROUNDS). 
BonOs. AWT.OR.MSL3(ALTERNATE WEAPON 1 OR MISSILE 3). 
AMMOY. AW2.OR.ADM(ALTERNATE WEAPON 2 OR AIR DEFENSE 
MESO LLE). 
VENTS SCHEDULED 


BN.ARRIVE( BATTALION ARRIVE). 
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PCODE(PLATOON CODE) (2-d). Holds the pointer value for a 
pratoon’s PCL.V. ITEMS (PLATOON CEASS V LPEMS). 

PLATOON. LEADER 

Rese REQ (RESUPPLY REQUEST). 

TANK 

TSTREAM(TRIP RANDOM NUMBER STREAM). 

CCODE(COMPANY AMMUNITION CODE). 

MAXTRIP(MAX TRIP). The maximum time required for a convoy ‘to 
reach its intended destination. 

MINTRIP(MIN TRIP). The minimum time required for a convoy to 
reach its intended destination. 


PERMANENT ATTRIBUTES (REAL) 


TIME.V 


ASSETS. Holds the amount of ammo left to be issued. 
DEL. Holds the amount of ammo initially delivered. 
NO.BATTLE. Indicates whether RES.REQs should be filled. 


"QO" indicates no 
"7" Indicates yes 
TEMP. Place holder for release point of the convoy. 


ROUTINES CALLED 


w 


COM.AMMNO, INT.F, B.CLASS.V 
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C.CGO. LIST (CONVOY CARGO LIST). 
CO.UNIT(COMPANY UNIT). 
CWANT. LIST (COMPANY WANT LIST). 
PLAT.UNIT(PLATOON UNIT). 
SREQN.LIST(SUPPLY REQUISITION LIST). 
SWANT.LIST (SUPPLY WANT LIST). 
TNK.ALIVE(TANK ALIVE). 

TEMPORARY ATTRIBUTES (INTEGER) 


AMMOS (AMMUNITION 5). Of TANK. 


AMMO6 (AMMUNITION 6). Of TANK. 


AP. TOW (ARMOR~OIERCING/TOW). Ammunition 1 OF TANK. 


TAC1. (TANK 
TAC2. (TANK 
TAC3. (TANK 
TAC. (TANK 
TACS. (TANK 


TAC6. (TANK 


AMMUNITION 


AMMUNITION 


AMMUNITION 


AMMUNITION 


AMMUNITION 


AMMUNITION 


AW1.OR.MSL3(ALTERNATE 


AW2.OR.ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE). 


Ammunition 4. 


CODE 


CODE 


CODE 


CODE 


CODE 


CODE 


WEoPON’ | OR MESSTLE 3). 


ie 
De 
We 
4). 
By) 


6). 


C.MV.STATE (CONVOY MOVEMENT STATE). 
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Ammunition 3. 





Seo tOonT (COMPANY SHORTAGE). Total rounds saort for a type 
ammo. 

COCDR (COMPANY COMMANDER). Of TANK. 

PRILL(FIREPOWER KILL). 

FLAG Yielding argument of W.AMMO and COM.AMMO, not used in 
this routine. 

HE.DRAG (HEAT/DRAGON ROUNDS). Ammunition 2 of TANK. 

RRIEULL (CATASTROPHIC KILL). 

MKILL(MOBILITY KILL). 

OH1(ON-HAND 1). Current balance of ammunition 1 on a TANK. 

OH2 (ON-HAND 2). Current balance of ammunition 2 on a TANK. 

OH3(ON-HAND 3). Current balance of ammunition 3 on a TANK. 

OH4 (ON-HAND 4). Current balance of ammunition 4 ona TANK. 

OHS (ON-HAND 5). Current balance of ammunition 5 on a TANK. 

OH6 (ON-HAND 6). Current balance of ammunition 6 on a TANK. 

P.SHORT (PLATOON SHORTAGE). Current shortage of a PCL.V.ITEM 
(PLATOON CLASS V ITEM). Unigue to each platoon and ammo 
type. 

PCURR. LOAD (PLATOON CURRENT LOAD). On-hand balance for an 
ammo type. Unigue for each platoon and ammo type. 


RAC (RESUPPLY AMMUNITICN CODE). 
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RCNVY (RESUPPLY CONVOY). 


(BATTALION ARRIVE) carrying the pointer of the convoy. 


REQUESTOR. 


specifying the unit making the request. 


REGLL(RESUPPLY FILL). 
REQUEST) 
fell a Eequest. 

RP (RELEASE POINT). 
convoy's destination. 

SLOAD1 (STOWED LOAD 1). Optimal 


SLOAD2(STOWED LOAD 2). Optimal 


SLOAD3 (STOWED LOAD Optimal 


SLOAD4 (STOWED LOAD Optimal 


SLOADS (STOWED LOAD Optimal 


SLOAD6 (STOWED LOAD 6). Optimal 


SP(START POINT). Attribute of a convoy specifying the 


convoy's origin. 
sratus. 
SYS.TYPE(SYSTEM TYPE). 
ROUTINES CALLED 
W.AMMO 


PEFORM.F, UP.DATE, 


PROGRAM LISTING 








load 


load 


load 


load 


load 


load 


1 EVENT CO.RESUPPLY. ARR(CNVY) 
2 DEFINE FLAG,NO.BATTLE, TEMP,CNVY,ASSETS, 


P24 |e: 


Attribute of a convoy 


aanamno 


anno 


anno 


ammo 


aamo 


ammo 


Attribute of a RES.REQ 


specifying the 


Argument of the event BN.ARRIVE 


Attribute of a RES.REQ(RESUPPLY REQUEST) 


(RESUPPLY 


specifying the amount of ammunition released to 


Indicates the current location of a convoy. 
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een cmd ceed med ek cme cd ced ch eee ceed ced ced eed oe) eed eed eed od ceed ed ed eed ed ed) ed eo) = od 


IF TACS (TANK) =BAC (RES. REQ) 
LET OHS(TANK) = OHS (TANK) = De 
S ADS (TANK) “OHS (TANK ) 
, SHORT (PCODE (PL TOON. LEADER, RAC (RES. REQ 
LEP AMEO (TANK) AMYOS TANK) +DEL 
« (SLO (PAVK) -AuOS (nat 
B. SHORT (PCODE ( IATOON LEAD R, RAC (RES. REQ 
GO TO TA 
7 OTHERWISE 
IF TAC6 (TANK) =RAC (RES. REQ) 
LET OH6 (TANK) OH6 (TAN ) + DEL 
C(S LOA D6 (TANK) -OH6 (TANK)) ) 
.. SHORT (PCODE (PLATOON , LEADER, RAC (RES. REQ) 
LEP ANNO (TANK) = AHNOG (TANK) +DEL 
CSLOAD6 (TANK) -AMMO6 (TANK) ) 
P. SHORT (PCODE (PLATOON. LEADER, RAC (RES. REQ) 
- ALWAYS 
'TANKLOOP! 
LOOP 
'OPDATEFILES! 
IF RES.REQ IS NOT IN SOME SWANT.LIST 
AND FES.REQ IS IN SOME CWANT.LIST, 
REMOVE RES. REQ 
PROM CWANT. LIST (REQUESTOR (RES. REQ) ) 
, ALWAYS 
IF RES.REQ IS NOT IN SOME SREQN.LIST 
PILE RES.REQ IN SREQN.LIST(SP ic NVY) ) 
ALWAYS 
LET STATUS (RES.REQ) = “ATP! 
LET DEL = 


LOOP 
BOR EVERY T 


ANK IN TNK.ALIVE 
WITH COCDR TANK) FQ RP (CNVY) ,DO 
IF SYS.TYDE (TANK) EQ 7, 
CYCLE 
OTHERWISE 
LET NO.BATTLE = 1 
CREL WIAMMO (TANK, NO.BATTLE) YIELDING FLAG 
1908 
FOR EVERY PLATOON.LEADER IN CO.UNIT(RP(CNVY)), DO 
Shhh F.CLASS.V (PLATOON.LEADER) 
LET NO.BATTLE = 1 
CALL COM.AMMO (RP(CNVY) ,NO.BATTLE) YIELDING FLAG 
''SEND THE CONVOY HOME 
LET TEMP = RP (CNVY) 
LET RP(CNVY) = SP (CNVY) 
LET SP(CNVY) = TEMP 
LET C.MV.ST TE (CNVY) = 1 
SCHEDULE ABN. ARRIVE (CNVY) 
IN UNIFORN.F (MINTRIP,MAXTRIP,TSTREAM) MINUTES 


a ade> we ek ES oe oe EE SE a OS ee ee = 


218 





Lines 2-3 Define the recursive variables used in the 
Bowe Tne. 

Line 4 Prints a message marking the start of the routine. 

Lines 6-7 Change the convoy movement state to zero. 

Line 9 Begins the routine's major loop over all resupply 
requests in the arriving convoys cargo list. Loop ends 
on line 104. 

Line 10 Captures the quantity delivered by the convoy as a 
local variable for computation purposes. 

Lines 12-13 Begin an inner loop over every platoon leader 
in the company in order to distribute the arriving 
Supplies. Loop ends on line 103. 

Lines 14-17 Set the delivery for a particular platoon equal 
to [platoon shortage / company shortage] multiplied by 
the deliver quantity. 

Line 18 Subtracts the delivery from tae assets available. 

Lines 19-20 Adjust the platoon current load for that ammo 
type. 

Line 22 Begins an inner loop over all the weapon systems in 
the platoon so that deliveries can be made. Loop ends on 


line 89. 
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Lines 24-27 Determine if any vehicle has sustained 
casualties, if so, the loop is cycled to the next weapon 
Systom. 

Lines 29-86 Check to see if the ammo delivered is one of 
the six carried on the TANK. If so, the weapon system's 


on-hand knowledge and actual knowledge is updated to 


= 
- 


i) 


flect the delivery. 

Lines 88-89 Close the combat vehicle locp begun on line 22. 
Transfer of control go2s to the next TANK or out to the 
next platoon. 

Lines 91-101 Update files by removing the request from 
company want lists and filing the same request ona 
supply request, simulating a request from battalion to 
the brigade ATP for more ammo. 

Line 102 Resets the delivery quantity to zero. 

Line 103 Closes out the platoon loop begun on line 12. 
iPaansces Of Control is to the next platoon or out to the 
next request. 

Line 104 Closes out the request loop begun on line 9. 
Transfer of control is to the next reguest or out. 

Lines 105-112 Cause every TANK in the company to update its 


ammo status. 
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Lines 114-116 Cause every platoon in the company to update 
its ammo status. 

Lines 117-118 Cause the company to uodate its ammo Status. 

Lines 120-126 Turn the convoy around and sends it back to 
the battalion supply point as a resupply coming from the 


ATP. 


eee GS VENT REDISTRIBUTE" 
This event is scheduled from event MOVE. It is used to 

evenly redistribute ammunition in a piatoon. 

P - Holds the pointer value of the platoon currently 
redistributing. 

DISTR (DISTRIBUTOR). Argument for the event REDISTRIBUTE 
holding the value of the unit's PLATOON. LEADER. 


EFINE TO MEAN 





AMMO1. AP. TOW (ARMOR PIERCING/TOW ROUNDS). 

AMMO2. HE.DRAG(HEAT/DRAGON ROUNDS). 

AMMO3. AW1.OR.MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). 
AMMOWY. AW2.OR.ADM(ALTERNATE WEAPON 2 OR AIR DEFENSE 


MISSILE). 


Peme¥. LTEM 


Pou 





Peomr {PLATOON CODE) (2-d). Holds the pointer value for a 
pecwoones PELLV.ITEMS(PLATOON CLASS V ITEMs). 


TANK 
TIME.V 


CASSETS. Current amount of an ammo type on-hand ina 
platoon. 

FLAG. Yielding argument for routine W.AMMO; not used in this 
routine. 

NO.BATTLE. Indicates whether RES.REQS should be filled. 


"gO" indicates no 
“qt indicates yes 
RASSETS. Required amount of an ammo type based on the 


platoons stowed load. 
ROUTINES CALLED 
P.CLASS.V, UP.DATE, W.AMMO 
SETS_USED 
PLAT.UNIT(PLATOON UNIT). Owned by a PLATOON. LEADER. Members 
acre the unit's combat vehicles(TANKs). 
PLT.AMMO (PLATOON AMMUNITION). Owned by a PLATOON. LEADER. 
Members are the unit's PCL.V.ITEMS (PLATOON CLASS V 
ite, 


EMPORARY ATTRIBUTE (INTEGER) . 





AMMOS (AMMUNITION 5). 

AMMO6 (AMMUNITION 6). 

AP. TOW (ARMOR~OIERCING/TOW) . Ammunition 1 

TAC1. (TANK AMMUNITION CODE 1). 

TAC2. (TANK AMMUNITION CODE 2). 

mee3.(TANK AMMUNITION CODE 3). 

TACY. (TANK AMMUNITION CODE 4). 

TACS. (TANK AMMUNITION CODE 5). 

TAC6.(TANK AMMUNITION CODE 6). 

AW1.OR.MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). Ammunition 3. 

AW2.O08.ADM (ALTERNATE WEAPON 2 OR AIR DEFENSE MISSILE). 
Ammunition 4. 

FKILL(FIREPOWER KILL). 

HE.DRAG(HEAT/DRAGON ROUNDS). Ammunition 2. 

Pee (CATASTROPHIC KILL). 

MFKILL (MOBILITY AND FIREPOWER KILL). 

MKILL (MOBILITY KILL). 

PAC (COMPANY AMMUNITION CODE). 

PCURR. LOAD (PLATOON CURRENT LOAD). On-hand balance for an 
ammo type. 

PL.B.LOAD(PLATOON BASIC LOAD). 

SLOAD1(STOWED LOAD 1). Optimal load ammo type 1. 


SLOAD2(STOWED LOAD 2). Optimal load ammo type 2. 


Zao 





SLOAD3(STOWED LOAD 3). Optimal load ammo type 3. 
SLOAD4Y (STOWED LOAD 4). Optimal load ammo type 4. 
SLOAD5 (STOWED LOAD 5). Optimal load ammo type 5. 
SLOAD6 (STOWED LOAD 6). Optimal load ammo type 6. 


PROGRAM LISTING 


1 EVENT REDISTRIBUTE (P) 
eens sr ease Teetsteys 207". 
4 PRING 1 LINE WITH TIME.V AS FOLLOWS 
i EVENT. REDISTRIBUTE CALLED AT TIME.V = #2. xx 2x 
B) FOR EVERY TANK IN PLAT.UNIT(P) ,DO 
7 LET NO.BATTLE = 1 
8 CALL W.AMMO (TANK,NO.BATTLE) YIELDING FLAG 
i ne 
ie CALL P.CLASS. ¥(P) 
12 FOR EVERY PCL.V.ITEM IN PLT AMMO (2) 
13 L2T CASSETS =" PCURR. LOAD (PCODE p, ROUND 
14 | LET RASSETS = PL.B.LOAD(PCODE (P, ROUND) 
iG FOR SVERY TANK IN PLAT.UNIT(P) ,DO 
17 If SKILL (TANK =1 OR MPKTLL (TANK) =1 
18 OR FATLL (TANK =1 OR KKILL (TANK) =1 
20 OTHERWISE 
De TF TACT (TANK) = PAC (PCL.V. ITEM) 
22 LET A MO1(TANK)=SLOAD1 (TANK) / 
E 
24 ALWAYS 
35 TF TAC2 (TANK) = PAC (PCL.V. ITEM) 
26 L2T ANHO2(TANK) = SLOAD1 (TANK) /RASSETS*CASSETS 
28 ALWAYS 
39 IF TACI (TANK) = PAC (PCL. V. ITEM) 
30 LET AMMOT(TANK) = SLOA ) /RASSETS*CASSETS 
BD ALWAYS 
33 TF TAC2 (TANK) = PAC (BCL. V. ITEM) 
34 LET A MO2(TANK) = SLOAD2 (TANK) /RASSETS*CASSETS 
36 ALWAYS 
37 IF TAC3 (TANK) = PAC (PCL. V, ITEM 
38 LET ANMO3 ( ANK) = SLOAD3 (TAN 
& 
40 ALWAYS 
ne TF TACU (TANK) = PAC (BCL. V ITEM 
42 LET AMMO4 ( ANK) = SLOAD4 (TAN 
nar ALWAYS 
45 IF TACS (TANK) = PAC(PCL.V.ITEM) 
46 LET MMOS (TANK) = SLOADS (TANK) /RASSETS*CASSETS 
YCLE 
48 ALWAYS 
49 IF TAC6 (TANK) = PAC(PCL.V.ITEM) 
50 LET A MO6 (TANK) = SLOAD6 (TANK) /RASSETS*CASSETS 
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RADOE Loe Asus 


1) /RASS ET S#CASSETS 


NK) /RASSETS*CASS BTS 





a) ALWAYS 

53 Or 

54 LOOP 

poeeloRn EVERY STANK IN PLAT.UNIT(P), DO 

56 LED WO] BATTS = 

57 CALL W.AMMO (TANK,NO. BATTLE) YIELDING FLAG 
598 LOOP 

99 CALL P.CLASS.V 

60 RETURN 

S1 END 


N 

EXPLANATION OF CODE 

Lines 2-3 Define recursive variables for use in the 
routine. 

Line 4 Prints a message marking the beginning of the 
routine. 

Lines 6-9 Update the platoon weapon system's current 
knowledge of its ammo status. 

Line 11 Updates the platoon's current ammo knowledge. 

Line 12 Begins the majer loop for the routine by looping 
over all ammo types carried by the platoon. Loop ends on 
line 54. 

Lines 13-14 Capture the current assets on-hand and the 
required assets needed to be on-hand for computations. 

Line 16 Begins an inner loop for the routine looping over 
all weapon systems in the platoon. Loop ends on line 53. 

Line 17-20 Check if a weapon has sustained battle damage. 


If so, the routine cycles to the next weapon. 
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Lines 21-52 Check if the ammo being considered is one of 
the weapons six ammunitions carried. If so, the weapon 
is given a percentage of the assets on-hand equal to 
[weapon stcwed load / platoon base load] muitiplied by 
the platoon's assets. 

Line 53 Closes out the inner loop cauSing the routine to 
loop to line 16 and the next weapon or out to the next 
ammo. 

Line 54 Closes out the major loop causing the routine to 
loop to line 12 and the next ammo type or out. 

Lines 55-58 Cause every TANK in the platoon to update its 
ammo status. 


Line 59 Causes the platocn to update its ammo status. 


me Ge VENT BN.ARRIVE® 


Event BN.ARRIVE is scheduled from CO.RESUPPLY.ARR to 
Simulate an RSV or convoy returning to the battalion trains 
after a resupply mission. The RSV or convoy returns to the 
battalion trains with an identical cargo to what it 
delivered to the resupplied company. Understandably, this 
is unrealistic but it serves the purpose of resupplying the 
battalion trains in the model. This cargo is now added to 
the battalion's assets and becomes available for resupply 


again. 
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rs 


ARGUMENTS 


RCNVY (RESUPPLY CONVOY). Argument of the event BN.ARRIVE 


(BATTALION ARRIVE) carrying the pointer of the convoy. 


BN.ARRIVE(BATTALION ARRIVE). 
GLOBAL_VARIABLES (INTEGER) 
SCODE (SUPPLY CODE) (2-d). Holds the pointer value for a 
supply unit's SCL.V.ITEMS(SUPPLY CLASS V ITEMs). 
TANK 


SS aS Sw Se SS SS SS Ee ee Se eS SS SS SS 


mene. V 


C2) 


SETS 

CARGO. Of a resupply truck. 

C.CGO.LIST (CONVOY CARGO LIST). Owned by a CONVOY. Members 
mee tie RES.REQS(RESUPPLY REQUEST) being shipped. 

ELEMENTS. Owned by a CONVOY. Members are trucks (TANKs) 
belonging to the convoy. 

SCONVOY (SUPPLY CONVOY). Owned by a SUPPLY.OFFICER. Members 


are CONVOY(s). 


See ONe LIST(SUPPLY REQUISITION LIST). Of a RES.REQ. 


CONVOY 


RES.REQ. (RESUPPLY REQUEST). 


eey 





fyeGO (TRUCK CARGO). 

C.MV.STATE (COMPANY MOVEMENT STATE). 

ONHAND 

RAC (RESUPPLY AMMO CODE). 

PEELL(RESUPPLY FILL). Attribute of a RES.REQ (RESUPPLY 
REQUEST) specifying the amount of ammunition released to 
Fill a request. 

RP(RELEASE POINT). Attribute of a CONVOY specifying the 
convoy's destinaticn. 

mer, (REQUIRED QUANTITY). Of a RES.REQ. 

ROUTINES CALLED 


UP.DATE 


EVENT BN. ~ARRI VE (RCNV ¥) 
DEFINE RCNVY AS AN INTEGER VARIABLE 
PRINT 1 LINE WITH TIME.V THUS 
EVENT BN.ARRIVE CALLED AT TIME.V = “t:, xox 
LET C.MV.STATE(RCNVY) = 0 
FOR EVERY RES.REQ IN C.CGO.LIST(RCNVY) ,DO 


2 

3 

uy 

5 Ce 

6 ADD RFILL(RES. REO) TO 

% ONHAND(SCODE (RP(RCNVY) ,RAC(RES. /REQ)) 
8 REMOVE RES. REO FROM C.CGO.LIST (RCN 

9 REMOVE RES.REO FROM 5 SREQN. “LIST (RP (RC VY)) 
10 I? ROPY (RES - .R ) = 0, 

17 DESTROY RES. REO 

12 ALWAYS 

13, LOOD 

14 FOR EVERY TANK IN ECan (RANK) DO 
15 FOR EVERY T.CGO IN CARGO(TANK), DO 
16 REMOVE T.CGO FROM CA8GO (TANK) 

17 DESTROY T.CGO 

18 LOOP 

19 5 gEnove TANK FROM ELEMENTS (RCNVY) 

a REMOVE RCNVY FROM SCONVOY (RP (RCNVY) ) 
22 DESTROY CONVOY CALLED RCNV 

23. RETURN 

24 END 
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EXPLANATION _OF_CODE 

Line 2 Defines recursive variables used in the routine. 

Line 3 Prints a message indicating that the routine has 
been called. 

Line 4 Changes the convoy move state to zero. 

Lines 5-13 Loop over every resupply request in the convoy 
adding its fill to the on-hand stocks at the battalion, 
removing it from the convoy cargo list and the S-4's 
request list. If the out standing baiance for the 
request is zero it is destroyed. 

Lines 14-20 Loop over every TANK in the convoy's elements 
removing the cargo entities from the trucks, and the 
trucks from the ccnvoys. The cargo entity is then 
destroyed. 

Lines 21-22 Remove the convoy from the S-4's list and 


destroys the convoy. 


ieee sc VENT UP.W.AMMO" 

Event UP.W.AMMO 1S initially scheduled in routine 
BLU.CREATE for 2ach weapon system in the model. It is used 
to call routine W.AMMO for a periodic update of ammo LONs. 


It subsequently randomly reschedules itself simulating the 
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Mecegulat Counting Of ammunition during combat. Based ona 
returning argument from routine W.AMMO, this event may 

schedule a platoon update if the weapon is critical for an 
ammo type, Or may stop scheduling updates for the weapon if 


damage has been sustained. 


RND.CNTR. Points to weapon currently updating. 


GLOBAL VARIABLE _(IN 


EGERL 


WSTREAM (WEAPON RANDOM NUMBER STREAM). 


WMAX(WEAPON MAXIMUM). The maximum time that can pass before 
a weapon will update its ammunition status. 
WMIN (WEAPON MINIMUM). The minimum time that can pass before 


a weapon will update its ammunition status. 


PFLAG. Yielding argument from W.AMMO. 
ROU ENeE Ss CALLED 


So a aes A aE ES oe eee ss 


UNIFORM.F, UP.PLT.AMMO (UPDATE PLATOON AMMO) 


TIME.V 
TEMPORARY ATTRIBUTE {LNTEGER) 


A - Holds pointer of weapon currently updating. 


BeroDR. Of TANK. 
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P.RND. CNTR (PLATCON ROUND COUNTER). Argument of event 


UP.PLT.AMMO pointing to a specific platoon which will 


update. 


PROGRAM _LISTING 


1 EVENT UP.W.AMMO(A) 
2 DEFINE NO.BATILE,A, AND FLAG AS INTEGER VARIABLES 
3 LET NO.BATTLE = 6 
4 CALL W.AMMO GIVEN A,;NO.BATTLE YIELDING FLAG 
5 IF PFLAG = 100, if EMERGENCY RESUPPLY NEEDED 
6 SCHEDULE AN’UP.PLT.AMMO(PLTLDP (A)) NOW 
7 PRINT 2 LINES WITH TIME.V THUS 
UP. PLT. AMMO CALLED BECAUSE OF ZERO BAL 
TIME. V = 8a, xan 
8 ALWAYS 
9 IF FLAG NE 1, os a BATTLE DAMAGE SUSTAINED 
10 SCHEDULE AN UP.W.AM O(a ) 
17 IN UNIFORM. F (WHiN, aM A STREAM) HOURS 
12 ALWAYS 
13. RETURN 
14 END 


Line 2 Defines recursive variables for the routine. 

Line 3-4 Set the index necessary to call for a battle 
update and calls routine W.AMMO. 

Lines 5-8 If the flag returned indicates that a weapon is 
at empty for an ammunition type, this provokes a call 
for the platoon to update its ammo. 

Lines 9-11 If the flag indicates that no battle damage has 


been sustained, the update is rescheduled. 


Ue "EVENT UP.PLT.AMNO" 


This event is initially scheduled from routine 


BLU.CREATE to call routine P.CLASS.V for a periodic ammo 
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update. It then randomly reschedules itself in order to 

Simulate a platoon leader checking individual weapons. 

Scheduling also occurs if a weapon reaches an LON cf "1" for 

an ammunition type Simulating the initiation of an emergency 

request. Additionally, based on a return argument from 
routine P.CLASS.V, this event may schedule a company update 
if the platoon is critical for an ammo type, or may stop 
scheduling updates for the platoon if all its weapons are 
incapacitated. 

P.RND.CNTR (PLATOON ROUND COUNTER). Argument of the event 
UP.PLT.AMMO (UPDATE PLATOON AMMUNITION) carrying the 
pointer value of the platoon currently updating. 

SET 

PLT.AMMO (PLATOON AMMUNITION). Owned by a PLATOON. LEADER. 
Members are the unit's PCL.V.ITEMS (PLATOON CLASS V 
ITEMS). 

EVENT_NOTICE 


UP.COM.AMMO(UPDATE COMPANY AMMUNITION). 


ae 





PMAX (PLATOON MAXIMUM). The maximum time a that can pass 
before a platoon will update its ammunition status. 
PMIN(PLATOON MINIMUM). The minimum time & that can pass 


before a platoon will update its ammunition status. 


PCO.COR(PLATOON COMPANY COMMANDER). 


N.PCL.V.ITEMS (NUMBER OF PLATOON CLASS V ITEMS). 


mos. V 


FLAG. Yielding argument from P.CLASS.V. 


OUTINES 


P.CLASS.V(PLATOON CLASS V AMMO), UNIFORM.P 


C.RND.CNTR (COMPANY ROUND COUNTER). Argument or the event 
UP.COM.AMMO (UPDATE COMPANY AMMUNITION) carrying the 
pointer value of the company currently updating. 

Meeeroints to platoon currently updating. 


PROGRAM LISTING 


EVENT UP.PLT. AMMO (J) 
DEFINE J,FLAG AS iNTEGER 
Girl CL CLASS.V GIVEN J YI 
IP FLAG = 1, 


I 
I 

SCHEDULE AN UP.COM.AMMO( CQ J)) NOW 
S 


F ZERO BAL 


ONUN 4 WIN) a 


PRINT 2 LINES WITH TIME. 
UP.COM.AMMO CALLED BECAU 
TIME. V = oe, acces 

ALWAYS 
IF PLAG NE N. PCL. V ITEMS (J) '*DLATOON STILL VIABLE 
T. AMMO (J) 


OO ~J 


SCHEDULE AN UP.PL 
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IN ee ee HOURS 


Line 2 Defines the recursive variables used in the routine. 

Line 3 Calls upon routine P.CLASS.V to update the platoon's 
ammo status. 

Lines 4-7 If the flag equals 1, this indicates that the 
platoon is at zero balance for an ammo type and the 
company is requested to update its ammo status. 

Lines 8-11 If the flag does not indicate that the platoon 
has sustained enough damage to place it out of combat, 


its next update is established. 


foe EVENT UP.COM. AMMO" 

Event UP.COM.AMMO is initially scheduled from routine 
BASIC.LOAD and subsequently randomly reschedules itself 
Slmulating the update of ammunition Pe coee within a company. 
It is also called immediately if a platoon reaches an LON of 
"1" for an ammunition type simulating the initiation of an 
emergency request. Additionally, based on a returned 
argument from routine COM.AMMO, this event may stop 


scheduling updates if all its platoons have been put hors de 


comba=. 
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C.RND.CNTR (COMPANY ROUND COUNTER). Argument for event 
UP.COM.AMMO (UPDATE COMPANY AMMUNITION) holding a 


Poenhees Of a company unit. 


CMAX (COMPANY MAXIMUM). The maximum time that can pass before 
a company will update its ammunition status. 

CMIN (COMPANY MINIMUM). The minimum time that can pass before 
a company will update its ammunition status. 


CSTREAM (COMPANY RANDOM NUMBER STREAM). 


Ae) 


ERMANENT ATTRIBUTES (INTEGER) 


i =—— a = Aa = = = = 


N.CCL.V.ITEMS (NUMBER COMPANY CLASS V ITEMS). 
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C ~ Points to company updating. 
FLAG. Yielding argument of routine COM.AMMO. 
NO.BATTLE. Indicates whether RES.REQS should be filled. 


"Oo" indicates no 


iw windi cates) yes 





COM. AMMO (COMPANY AMMO), UNIFORM.F 


EVENT UD.COM. AMMO (C) 
DEFINE NO.BATTLE,C,FLAG AS INTEGER VARIABLES 
LET NO.BATTLE = 0 

CALL COM.AMMO GIVEN C,NO.BATTLE YIELDING FLAG 


& (WN «a 
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> IF FLAG NE A UDCCOM: AMMO IC ’ 

6 SCHEDULE A UP.COM. AMMO (C 

7 IN UNIFORM. F (CHIN, CMAX,CSTREAM) HOURS 
8 ALWAYS 

9 RETURN 

POs EN 


Line 2 Defines the recursive variables used in the routine. 

Lines 3-4 Sat the indicator flag to require requisitions to 
be filed and calls routine COM.AMMO. 

Lines 5-8 If the indicator flag returned indicates that the 
company is still a viable combat entity, its next update 


is scheduled. 


freee  SVENT B.UP.DATE" 

Event B.UP.DATE is initially scheduled in the main 
program to initiate a periodic call for a battle summary 
from routine UP.DATE. This event subsequently reschedules 
itself every 24 hours. 


TiMe.V 


moenc.F, UP.DATE 


PROGRAM LISTING 


1 EVENT B.UP.DATE 

2 CALL UP.DATE 

SeeescCHSDULE A B. UP. DATE) AT ™TRUNC.F(TIME.V) + 1 
4 RETURN 

5 END 


EXPLANATION OF CODE 


<P cp = ee ae ca ee eee SS ee eee 
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bone 2 Cails routine UP.DATE to print a battle summary. 


Line 3 Schedules another update in 24 hours. 


moe "SVENT STOP.SIMULATION*" 
Event STOP.SIMULATION is called from the main program at 
+he scheduled time to stop the simulation. It causes a 


final printout of the battle summary to be produced. 


ern. V 
ROUTINES CALLED 
VES DATS 
PROGRAM LISTING 
1 EVENT STOP.SIMULATION 
Z ior TIME. V 
3 CALL UP.DATE 
2 Sor 


END 
EXPLANATION OF CODE 
Line 2 Prints the time the simulation ended. 

Pine 3 Calls routine UP.DATE to print a final battle 


summary. 


meee ovENT UP.S4.AMMO"™ 


This event is scheduled by event COM.AMMO when a 
resupply request is created. The purpose of event 


UP.S4. AMMO is to process requests for and issue ammo fron 


PAV | 





+he batcalion's reserve stocks of ammunition. In execution, 
the event performs the following functions: prioritization 
of outstanding requests; assessment of quantities to be 
relsased to fill requests subject to transportation 
muetlability; creation of convoys to carry the supplies; 
creation of cargo manifests for individual trucks; and the 
dispatch of convoys from the supply point. Lastly, the 
event schedules the convoy arrival (CO.RESUPPLY.ARR). 
ARGUMENTS 
ISSUEE. Argument for the routine containing the unit 
requesting resupply. 
ISSUER. Argument for the routine containing the pointer of 
the supply officer updating. 
GLOBAL_VARIABLES (INTEGER) 


BeODE (SUPPLY CODE) (2-d). HOLDS POINTER FOR SCL.V.ITEM. 


GLOBAL VARIABLES (REAL) 


SSE a SS 





CL1.PCT(CRITICAL LON1 PERCENT). 
mew ect (CRITICAL LON2 PERCENT). 
MAX.TRIP. Maximum travel time to a unit. 
MIN.TRIP. Minimum travel time to a unit. 


SCODE (SUPPLY CODE). 


N.SCONVOY(NUMBER IN SUPPLY CONVOY). 
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NeoWANT «LIST (NOMNBER IN SUPPLY WANT LIST). 
BeQ.COR(SUPPLY COMPANY COMMAWDER). 


PERMANENT ATTRIBUTE (REAL) 
TIME.V 
RECURSIVE VARTABLES_ (INTEGER). 

A - Holds pointer to S-4 updating. 

COM. Holds pointer to company updating. 

CON.ID (CONVOY ID). Holds the pointer value of the convoy 
eWrrently being filled. 

IT.LIVES. Indicates if a convoy has already been created to 
Sa=ry SUDplies tO a particular unit. 

ZT = Loop index. 

hee GOOD index. 

N.RNDS (NUMBER CF ROUNDS). Holds the number of rounds being 
released +o fill a regvest. 

RC. TEMP (ROUND/CUBE TEMPORARY). Holds the computational value 
or the number of rounds that may be loaded on a truck 
due to cube restrictions. 

RNDS (ROUNDS). Holds the number of rounds being released to 
fill a request. 


RR(RESGPPLY REQUEST). Holds the pointer of the resupply 


request being currently filled. 
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RW. TEMP (ROUND/WEIGHT TEMPORARY). Holds the computational 
value of the number of rounds that may be loaded on 4 
<cruck due to weignt restrictions. 

T.COUNT(TRUCK COUNT). Holds the value of the number of 
trucks already loaded for a particular resupply request. 

TRKS.AVAIL (TRUCKS.AVAILABLE). Holds the total number of 
*rucks available for assignment to a resupply mission. 

CU(CUBE). Holds the maximum cube that may be loaded ona 
resupply vehicle. 

CU.AVAIL(CUBE AVAILABLE). Holds the total cube capacicy thar 
is available within the supply unit for the shipment of 
supplies. 

CU.REQ (CUBE REQUIRED). Holds the total cube that is required 
in order to ship a resupply reguest. 

LON1. Variable which indicates whether Level of Need 1 
requests are currently filed with the supply officer. 

LON2. Variable which indicates whether Level of Need 2 
requests are currently filed with the supply officer. 

MUOLI(MULTIPLIER 1). Holds the multiplier for LON 1 requests 
which is used to reduce the fill on such requests. 

MUL2 (MULTIPLIER 2). Holds the multiplier for LON 2 requests 


which is used to reduce the fi11 on such requests. 
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MULT (MULTIPLIER). Holds the multipiier for both LON 1 and 
LON 2 requests in the main part of the computations. 

PCT(PERCENTAGE) . Holds the percentage value of the amount 
released to fill a reguest versus the total quantity 
requested. 

RCU(RESIDUAL CUBE). The cube remaining in a CONVOY to be 
filled. 

RHT(RESIDUAL WEIGHT). The weight remaining in a CONVOY to be 
filled. 

WI (WEIGHT). Holds the maximum weight that may be loaded on a 
resupply vehicle. 

WE.AVAIL(WEIGHT AVAILABLE). Holds the total weight capacity 
that 1s available within the supply unit for the 
shipment of supplies. 

WIT.REQ (WEIGHT REQUIRED). Holds the total weight that is 
required in order to ship a resupply request. 


OUTINES CALLED 





Pros. UPDATE LOAD. TE Baw tEUCK 
MAX.F AN. 
PRI.RESUPPLY TRUNC.S 
UNIFORSM.F UP.DATE 
WT.AND. CUBE 

SETS 
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BeecO.LIST (COMPANY CARGO LIST). Contains a master listing of 
the RES.REQs that are loaded on the trucks belonging to 
meme set ELEMENTS (of @ convoy). 

CARGO. Contains a listing of the T.CGO loaded on a 
Barcicular «ruck. 

CWANT. LIST (COMPANY WANT LIST). Contains a listing of all 
outstanding RES.REQs belonging to a company. 

SCONVOY (SUPPLY CONVOY). Contains a listing of all CONVOYs 
the supply officer currently has active. 

Meer. LIST({SUPPLY WANT LIST). A list of all outstanding 
requests the supply officer has. 

TEMPORARY ENTITIES 

CONVOY. An entity created to move supply trucks (TANKs). 
around the battlefield with supplies. It contains the 
PeceGLEMENTS which holds the pointers of the trucks 
assigned to the mission. 

RESOeREQ (RESUPPLY REQUEST). 


T.CGO(TRUCK CARGO). An entity created to identify the cargo 


loaded on a supply truck (TANK). 


RNOMEN (RESUPPLY NOMENCLATURE). Attribute of an SCL.V.ITEM 


containing the name of the particular ammo type. 
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STATUS. Transmits information as to where a RES.REQ is in 
relation to the supply system. Values can be: TOS4&, ATP, 
mOCO. 

TNOMEN (TRUCK NOMENCLATURE). Contains the name of a 
particular ammo type. 

C.MV.STATE(CONVOY MOVEMENT STATE). Indicates if a convoy is 
in transit between supply points. 


"go" indicates no 
“1 indicates yes. 
CO.CNVY (COMPANY CONVOY). Argument of the routine 


CO.RESUPPLY.ARR holding the pointer of the convoy 
mers Vving. 

CONTRKS (CONVOY TRUCKS). Contains the number of trucks 
assigned +o a convoy. 

CPNTR (CONVOY POINTER). Holds the pointer value for an active 
CONVOY. 

L.ELEMENTS (LAST ELEMENT). System variable pointing at the 
last truck in a CONVOY's ELEMENTS set. 

M.C.CGO.LIST (MEMBER CONVOY CARGO LIST). System generated 
attribute which indicates whether a RES.REQ is filed in 


a convoy. 
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MeyrrSstT. Holds the pointer of the CONVOY a RES.REQ is 
loaded on. 

N.C.CGO.LIST({NUMBER IN COMPANY CARGO LIST). Indicates the 
total number of RES.REQs filed in a CONVOY. 

N.CARGO (NUMBER IN CARGO). Indicates the total number of 
T.CGO items loaded on a particular truck. 

N.T.ALLOC(NUMBER OF TRUCKS ALLOCATED). Contains the number 
of trucks to be allocated to move the rounds released 
for a resupply reguest. 

ONHAND. Holds the on-hand balance for rounds of a particular 
ammo type at the resupply point. 

RAC (RESUPPLY AMMUNITION CODE). 

RDS.PKG (ROUNDS FER PACKAGE). 

REQUESTOR. Contains the pointer to the unit requesting 
@-supply. 

RFILL(REQUEST FILL). Holds the number of rounds released to 
fill a request. 

RP{RELEASE POINT). Convoy termination point. 

ROTY (REQUIRED QUANTITY). 

RRPNTR (RESUPPLY REQUEST POINTER). 

SCREEN. Indicates whether a reguest has been reviewed during 
@ particular S-4 update cycle. 


SP(START POINT). Convoy start point. 
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SPACE. Indicates if empty space remains on trucks within a 
CONVOY. 

SPRIORITY(SUPPLY PRIORITY). Indicates the urgency of need on 
oe RES. REQ. 

TCU(TRUCK CUBE). The cube that a truck has available to be 
mi lied. 

BenrR (TRUCK POINTER). 

TOTY (TRUCK QUANTITY). Holds the number of rounds within a 
T.CGO that are loaded on a truck. 

TRAC (TRUCK AMMUNITION CODE). Of a T.CGO item. 

TWI(TRUOCK WEIGHT). The weight that a truck has available <o 


be filled. 


CU.PKG (CUBE PACKAGE). Of a standard package of ammo. 
WI.PKG (WEIGHT PACKAGE). Of a Standard package of ammo. 


PROGRAM LISTING 


1 EVENT UP.S4.AMMO (A,COM) 
2 DEFINE R.RNDS,A,1,K,COM,RW.TEMP, RC. TEMP, RNDS 

3 IT.LIVES,T.COONT,N.RNDS,CON.ID,RR 

& AND TRKS.AVALL AS INTEGER VARIABLE 

5 DEFINE MUL1,MUL2,LON1,LON2,CU,CU.AVAIL,CU.REQ,PCT, 
6 MULT, WT,WT. AVAIL, WT. REQ,RWT,RCU AS REAL VARIABLES 
7 PRINT 1° LINE WITH TIME.V AS’ FOLLOWS . 

f /EVENT UB.S4.AMMO CALLED AT TIME.V = %#,#Re 

9 CALL FILE.UPDATE(A,COM) 

10 CALL WE.AND.CUBE GIVEN A 
11 YIELDING WP.AVAIL,CU.AVAIL,TRKS.AVAIL,WT,CU 
12 ‘TEST IF RESUPPLY MISSIONS ARE POSSIBLE 

14 iF TRKS.AVAIL = 0 
15 RETURN 
1 OTHERWISE 

18 CALI PRI.RESUPPLY GIVEN WT.AVAIL,CU.AVAIL, 
19 YIELDING MUL1, AUL2 AON T LOND 
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CO 20 C0000. WO WII SYS SANHAAAAAAAHAOINIUNINNNNN EE EERE SES BWWWWWWWWWWdNNDonNNwynNph 
SON EWN BROW ONDE WN 2 OW WO SONU WP @OUW DIA EWN BOW DYNA E WN BOW ONOAUIE WI) 3 OWD TOQUE WN 2O 


VATE DAN 
FOR EVERY 
WITH ae: 
, AND M. 


‘ 
RecmneOmei s,eluMme BY CRITICALITY, BY TIME 
1 Lom, Do 


ae OST CRITICAL UNIT 
a RI 
GO. 
= 
N 


TWO Wicd 
BI" 2 


Vea EeK 
fF SoCRee 
CYCLE 

OTHERWISE 
Let SCREEN (RES.REQ) = 1 


''DETER IF THE AMMO IS ON-HAND AT SUPPLY POINT 
IF ONHAND (SCODE(A, BAC (RES. REQ) ) ) EO 0 


t 
F OVER REC 
S.REQ_ 1 IN 
TY (RES S.RE 
LIST (RES. 
CREEN 
(RES. 


REQ) 


i) 
= 
% 


CYC 
ALWAYS 
't SET MULTIPLIERS 
LET MULT = 
IP SPRIORITY (RES.REQ) = 1, 
LET MULT = MUL1 
ALWAYS 
IF SPRIORITY (RES.REQ) = 2, 
LET MULT = MUL2 
ALWAYS 
DETER IF THERE IS ENOUGH AMMO TO MEET REQUNTS 
LET NeRNDS = ROTY RES REQ) * MULT 
LET R.RNDS = ROTY(RES. REO 
IF N.RNDS GT ONHA D(SCODE (A, RAC (RES- REQ) } | 
LET N.RNDS = ONHAND(SCODE(A, RAC (RES.REQ))) 
ALWAYS 
''DETERMINE THE WT AND CUBE TO BE SHIPPED 
LET WT. REOQ=N. RNDS* T-PKG (SCODE (A, RAC (RES. REQ) ) ) 
RDS.PKG(SCODE (A AC (RE -REQ) LD 
LET CU.REQ= N.RNDS#CU. PKG (SCODE (A, RAC (RES. REQ) )) 
S. PKG (SCODE (A, RAC (RES. REQ) )) 
'' DETER IF A UNIT CONVOY IS ALREADY FORMED 
FOR EVERY CONVOY IN SCONVO¥( A) 
WITH C.MV.STATE(CONVOY) = 0 AND SP(CONVOY) = A 
AND RP (CONVO ¥ = RE UZSTOR (RES. REQ) DO 
''CAPTURE THE POINTER VALUE OF THE CONVOY 
LET CON.ID = CONVOY 


DEtetis LIVES = 1 
eCeEGR OIF SPACE a2. AVAIL ON CONVOY TRUCKS 


Phrroe AcE (CONVOY aE 
EF WT. aie GT i? (L ELEME NES Benny h 
U REO Goal ELEMENTS ey Y)) 
LET RWT = TaT 1. BLEMENTS CON ¥} 4 
LET RCU = TCU he CONVOY 
LoT RW.TEMP=R 
vat. PKG SCODE (A HAG (RES. REO) )4 
* RDS.PKG(SCODE (A,RAC (RES. REQ 
LET RC.TEMP = RCU 
/CU.PKG SCODE(A;RAC {RES 50) }) 
) 


* RDS. PKG (SCODE(A,RAC (RES. REQ 


LET RNDS = MIN.F (RW. TEMP, KC. TEMP) 
LET SPACE(CONVOY) = 0 

ELSE 
LET RNDS = N.RNDS 

ALWAYS 
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m@OOOYNHAMNIES WN 2OVY O~YWAMNE WH a OW OYNOANE WN Om OO OWNS WR BOW OWN NEWNDYH mOWOOWNUIES WN 2OWO 


co ew ge woh ee eed qe woe wed ed ee ow eed od ed od eed ot —0) ot 0d ed eed ed et od 0) et od od 0d ) —="60d) ot ot et 6d) SS med wh gah wh gee TD ge eee ee wh wah cond gh od 


IF RNDS le QO, 
e) | ee endfill 
otherwise 
Saoeae A eCGO 
BNER{ T. CGO) = L 
eR RRONT a CG 
LET TNOMEN «CGO 


TS (CONVOY) 
Pen) 


mont 


iHrreOoNnwywe 
ta 


WOAMaA AGONCONNHS!rPNnwWOwW KP NS 


ONVOY 
RES. REQ. 


bt tt 


D 

) Q) + RNDS 
LET ROTY (RES. REQ NDS 

‘tREDUCE THE ON-HA 

LET ONHAND (SCODE A 

ONHAND (SCO 

'tREDUCE THE WEIGH 

LET WT.REQ= TRUNC. 

*WT. PK 

/RDS.PKG 

LET CU.REQ= TRON 


/RDS.P 
t*REDUCE THE WT 
TRUCK 


LET THE (1. ELEMENT 
: aNDS* RT. 2 { 
PKG (SC 


OOe* Os awh 
WmOwWMOp Wht KHaZOr bike 


om OZ~ OQ WO? ““rybIe 


ODO oeR aon” Mb 
a={HwMNiwo bo" w~’bi 


K 
C 
Ie 
K 
A 


MW wane 


ws Orn< mwOOe 
pe 9 A Cem, Si 
tdtu<m 8 OG 
MOrmo wyio 
"OG Nes 


MANIFEST 
IN SOME SCONVOY 
SCONVOY (A) 


e 
= 
© Ha 


N C.CGO.LIST, 
N C.CGO. LIST (CON.ID) 


ES.REQ) = CON.ID 
S.REQ) = "TOCOMFANY" 


ae = 

STLOOP 
A 

*END.SPACE.CHECK' LOOP 


Picnioey & 
PeCHEGRK ONUONEGR OF FRUCKS AVAIL FOR SHIPMENT 
IF TRKS.AVAIL He 0 
GO TO FINALCHECK 
OTHERWISE 


Prir A CONVOY a a Bator CREATE ONE 


e 
Ge wed wae HNO 


MrdWMid Oro 
On-~ MN 
tibdttie. tO 


ame 
ry 
mm 
 @) 
Po | 
OK pw 
YON mtAHW wey OHEH 


Muomay ite OUZmz 


CONVOY 


Y 
EQUESTOR (RES. REQ) 


bo O 


"DETERMINE THE # OF TRKS ARE ON-HAND 
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Line 7 


oe olewnOr ADJUST 
IF WE.rEQ LT WE. AVAIL AND CU.REQ LT CU.AVAIL, 
LET N.T.ALLOC(RES. REQ) 
4 TRUNC.F (MAX. F (WT. REQ/¥T, CUSREQO7CU) + 1) 
L 


ET N.T.ALLOC(RES.REQ) = TRKS.AVAIL 
LWA 
ET TRKS.AVAIL = TRKS.AVAIL-N.T.ALLOC (RES. REQ) 
LL IN CONVOY MANIFEST 
ON.ID IS NOT IN SOME SCONVOY 
z CON.ID IN SCONVOY (a) 
§.REQ NOT IN C.CGO.LIST, 


L 

ae 

i oS TAS (RES oR EQ) = “TOCOMPANY" 
ve Reoeno LN  CaeGO.LIstT (CON.ID) 
M 
N 
R 


re fy 
r< 
WN 


; 
J 
L 
i 


He He 


S 
L 
W 
ak 
i 
3 
W 
L 
F 
W 


a 
C 
iE 
A 
A 
E 
T 
A 


4 


ANIPEST (RES. ;REQ). = CON.ID 
(RES. REQ) TO CONTRKS (CON.ID) 


R 
L LOAD. ‘TEE. RT UCKS 
(A,RR,WT.REQ,CU.REQ, N.RNDS,CON.ID) 


'' ADJUST THE WT.AND CUBE AVAIL FOR SHIPPING 
CALL WT.AND.CUBE GIVEN A 
YIELDING WT.AVAIL,CU.AVAIL,TRKS .AVAIL,#IT,CU 


pee 


Bh 
D 
Ay 
L 


 REGUE So LLOOF * 
-"UPRDALTE SWANT.LIST FILES 
LET PCT = R. Stee at 2 ORES: so 
jy seer ORT Ty ( Rios 25.0) ~. AND PCT GT C. ET 
mee PREORETY (KES. eee = ANDeEGE.GT C.L2Z22CT) 
Si Si Roo. site aa SWANT. LIST (A) 
REMOVE KES.REQ FROM SWANT.LIST (A) 
ee ALWAYS 
- LET IT.LIVES = Q 
LOOP 
190% 
‘* DISPATCH ALL CONVOYS CREATED 
FOR EVERY CONVOY IN E(CONYOR) 
WITH C.MV.STATE(CONVOY)=0 AND SP(CONVOY)=A, DO 
Pol eee uv so LATE (CONV 
LO0F 


© 


IF CON.ID NE 
SCHEDULE A CO. RESUPPLY.ARR (CON. ID) 
UNIFORM. F(MINTRIP,MAXTRIP,TSTREAM) MINUTES 
ALWAYS 


mekEoEd LOOP CHECKS 
PORMALLORsS.h 50 ITN CWANT .LIST(SCO.CDR(A)), DO 
aace. SCREEN(RES.REQ) = 0 


RETURN 
END 


EXPLANATION OF CODE 


i+ 
= 


Prints a message marking the beginning of the évent. 
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Line 9 Calls routine FILE.UPDATE which files new requests 
and checks cold reguests for duplication. 

Lines 10-11 Calls routine WEIGHT.AND.CUBE to assess the 
total weight and cube capacity available to handle 
Shipments of supplies forward. 

Lines 13-16 Check if all resupply vehicles are already in 
use. If so, the routine is ended with no further action 
caken. 

Line 18-19 Calls routine PRI.RESUPPLY to determine 1f£ LON1 
and LON2 requests should be modified in order to fill 
more requests with a lesser amount of ammo. 

memes 21-23 Start the majcr loop of the routine. Initialize 
an index to the most urgent LON a resupply request can 
have and begin +he loop which will fill requests. Loop 
ends on line 192. 

memes 25-28 Start an inner loop of the routine to identify 
the most critical resupply request on-hand to fill 
Berst. Loop ends on line 191. 

Lines 30-34 Check the screen attribute of a resupply 
request to determine if the request has been reviewed 
before in the current cycle. If the reguest has been 


reviewed, the request is cycled. 


249 





Lines 36-39 Check the availability of the ammo requested at 
the supply point. If none is available the request is 
cycled. 

Lines 41-48 Set multipliers for high priority requests as 
appropriate. The purpose of the multipliers is to 
reduce the fill on high priority requests in ord2r to 
release truck space to fill more high priority requests. 

Lines 50-55 Determine if there is enough ammo available to 
ae). 1 requests. If not, the request is filled with whac 
is available. 

Lines 57-61 Determine the weight and cube needed to ship 
the number of rounds requested. 

Lines 63-66 Start an inner loop which checks to see if a 
convoy is already formed for requestor of the current 
request. If one exists, this loop is entered and any 
available space on trucks already committed to the 
convoy is filled before more trucks are committed. Loop 
ends on line 134. 

Line 68 Captures the pointer value of the convoy formed. 

Line 69 Initializes a variable signifying that a convoy is 


already formed for the unit. 
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Lines 72-128 Perform an IF check to determine if space is 
fee eavalrtabls on convoy trucks. If so, the logic 
embedded to line 133 is executed; if not, control is 
meansterred to line 133. 

Lines 73-87 Perform an IF check to compute the number of 
rounds that may be shipped on the convoy subject to the 
available weight and cube. Satisfying tne IF condition 
indicates that the current request will fill the room 
available. Transfer to the ELSE condition indicates that 
the request will leave space on trucks for additional 
requests. 

Line 75 Computes the residual weight available on the 
convoy. 

Line 76 Computes the residual cube available on the convoy. 

Lines 77-79 Compute the rceunds that may be shipped for a 
request subject to the weight limitations of the truck. 

Lines 80-82 Compute «he rounds that may be shipped for the 
request subject tc the cube limitations of the truck. 

Line 33 Specifies the number of rounds to be released 
subject to the minimum restriction. 

Line 84 Sets the space attribute of the convoy to indicate 


that there is no space available. 
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Lines 85-86 Mark the ELSE logic which indicates that the 
request may be filled with room to spare. 

Line 87 Marks the end of the weight and cube loop. 

Lines 89-121 Perform an IF check to see if rounds are to be 
loaded on ccmmitted convoy trucks. If RNDS is greater 
than zero, the logic to load the truck is executed. If 
Mot, control is passed to line 133. 

Line 92 Creates a T.CGO to hold information as to the type 
and quantity of ammo to be loaded on a truck. 

Line 93 Captures the pointer value of the truck the cargo 
1s loaded on. 

Line 94 Captures the pointer value of the resupply request 
being filled. 

Line 95 Captures the nomenclature of the request being 
eeelled. 

Line 96 Captures the ammunition code of the request being 
mt led. 

Line 97 Captures the guantity being loaded on the truck. 

Line 98 Files the cargo on the last truck in the convoy. 

Lines 99-100 Reduce the number of rounds yet to be filled 


for the request. 
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Line 101 Adds the quantity released to the fill attribute 
of the request. 

Line 102 Reduces the reguired guantity for the resupply 
request. 

Lines 103-105 Reduce the on-hand stocks for the ammo type 
at the supply point. 

Lines 106-111 Reduce the weight and cube required to fill 
the request. 

Lines 113-120 Reduce the weight and cube available on the 
truck to fill requests. 

mene 1271 Closes out the inner IF check. 

Lines 121-132 Fill in the convoy manifest. 

Lines 125-127 Check if the existing convoy is in the set of 
convoys owned by the supply officer. If not, the convoy 
ms filed. 

Line 128 Points the resupply request to the convoy it is 
loaded on. 

Line 129 Insures that the status of the convoy shows ict 
enroute to the supported unit. 

Lines 130-132 Check to see if the request has been filled. 
If so the loop is cycled to the next request. If not, 
logic continues to see if it can be loaded on an 


additional truck for the convoy. 





Lines 136-140 Determine it there are trucks available for 
assignment to the convoy. If not, all loops are 
terminated. 

Lines 142-149 Make a check to determine if a convoy is 
already formed to ship supplies to the unit. If nota 
convey is formed, and attributes are Set capturing its 
pointer value, start point, release point(end point), 
and setting a variable egual to its pointer value for 
later computations. 

Lines 151-159 Determine if the necessary number of «trucks 
are available to ship the supplies. If not, the number 
of trucks that are available are assigned to the 
mission. 

Danes 161-173 Fill in the convoy manifest. 

Lines 162-164 Check if the existing convoy is in the set of 
convoys owned by the supply officer. If not, the convoy 
ms Liled. 

Lines 165-168 Check if the resupply request is filed in tae 
convoy manifest. If not, the convoy is filed and the 
status changed to show enroute to the supported unit. 

Line 169 Points the resupply request to the convoy it is 


loaded on. 
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Line 170 Adds the number of trucks allocated to the 
eoivey s ~Otal. 

Lines 171-172 Capture the resupply pointer and transfer 
control to a routine which loads the request on the 
e=neks. 

Lines 175-177 Call routine WEIGHT.AND.CUSE again to update 
the weight and cube now available on trucks at the 
Bactalion ¢rains for shipping. 

Lines 179-187 Update S-4 request files dropping those LON 1 
and LON 2 files that have been filed past a critical 
minimum and dropping all other requests that have at 
feast a partial fill. 

Line 189 Resets the IT.LIVES variable to zero. 

Lin2 191 Closes out the inner loop started on line 25 
carrying with it the most critical reguest. Transfers 
control back to acquire the next request or out to the 
next LON value. 

Line 192 Closes out the major loop started on line 21. 
Transfers control back to change the LON value being 
considered to the next value or out. 

Lines 194-198 Change the movement state of all convoys 


created in order to dispatch the convoys. 
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Lines 200-203 Determine if convoys have been formed this 
iteration of the routine. If so, a company resupply 
arrival time is scheduled. 

Lines 205-208 Reset the screen attribute on still viable 


requests for the next iteration of the loop. 


ae TS VENT FIREKILL" 

This event is scheduled by event UP.W.AMMO if a weapon 
system sustains a firepower kill. The purpose of the event 
is to redistribute the weapon system's on-board ammo +o the 
other members of its platcon. In execution, each of the six 
ammo types a weapon cculd carry are removed from the weapon 
and distributed to the other undamaged weapons in the 
platoon in accordance with each weapon's urgency of need for 


*hat ammo type. 


VICTIM. Points to the weapon system that has been killed. 


AMMO1. AP.TOW(ARMOR PIERCING/TOW ROUNDS). 

AMMO2. HE. DRAG(HEAT/DRAGON ROUNDS). 

AMMO3. AW1.OR.MSL3 (ALTERNATE WEAPON 1 OR MISSILE 3). 

AMMOU. AW2.OR.ADM(ALTERNATE WEAPON 2 OR AIR DEFENSE 
MISSILE). 


GLOBAL VARIABLES _ (INTEGER) 


SSl Sa: Sa Se = = 
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MeQODE (PLATOON CODE) (2-d). Holds the pointer value for a 
Paeoon'’s PCL.VY.ETEMS (PLATOON CLASS V ITEMs). 
RECURSIVE VARIABLES _ (INTEGER) 
A - Points to the weapon killed. 
AC. Holds the value of the ammo code being reviewed. 
DEL. Placeholder for ammunition types being delivered. 
im= Loop index. 


NO.BATTLE. Indicates whether RES.REQS should be filled. 


"oO" indicates no 
"1" indicates yes 
PL. Points to a PLATOON. LEADER. 
TK. Points to a TANK. 
ROUTINES _ CALLED 


PeeUATE, We-AMMO, P.CLASS.V 


ETS 


SED 
PLAT.UNIT( PLATOON UNIT). Owned by a platoon.leader. Members 
are the unit's combat vehicles (TANKs). 
TEMPORARY ATTRIBUTES (INTEGER) 
AMMOS (AMMUNITION 5). Of TANK. 
AMMO6 (AMMUNITION 6). Of TANK. 


AP. TOW (ARMOR-PIERCING/TOW) . Ammunition 1 of TANK. 


AW1.OR.MSL3(ALTERNATE WEAPON 1 OR MISSILE 3). Ammunition 3. 


Pat | 





meson. ADM{ALTERNATE WEAPON 2 OR AIReDEFENSE MISSILE). 


Ammunition 4&. 


HE.DRAG (HEAT/DRAGON ROUNDS). 


FKILL (FIREPOWER KILL). 


PLAG. 


KKILL(CATASTROPHIC KILL). 


MFPKILL (MOBILITY AND FIREPOWER KILL). 


MAILL(MOBILITY KILL). 


OH1(ON-HAND 1). 
OH2(ON-HAND 2). 
OH3(ON-HAND 3). 
OH4 (ON-HAND 4). 
OH5 (ON-HAND 5). 


OH6 (ON-HAND 6). 


P.SHORT (PLATOON SHORTAGE). 


(PLATOON CLASS V ITEM). 


+ype. 


Current 


Current 


Current 


Current 


CUEEent 


CUuELeSi= 


PLTLDR (PLATOON LEADER). 


SLOAD1(STOWED 
SLOAD2 (STOWED 
SLOAD3 (STOWED 
SLOAD4 (STO WED 


SLOADS (STOWED 


LOAD 1). 
LOAD 2). 
LOAD 3). 
LOAD 4). 


LOAD 5). 


balance 


balance 


balance 


balance 


balance 


palance 


Curg 


Uni 


Cptinal 
Optimal 
Optimal 
Optimal 


Optimal 


of 
of 
of 
ene 
of 
or 


ent 


que 


load 


load 


load 


load 


load 
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ammunition 


ammunition 


ammunition 


ammunition 


ammunition 


Uy 


5 


Amaunation 2 Of TANK. 


on 


On 


On 


on 


on 


ammunition 6 on 


Yielding argument of routine W.AMMO; not used. 


a 


TANK. 


TANK. 


TANK. 


TANK. 


TANK. 


TANK. 


shortage of a PCL.V.ITEM 


to each platoon and anmo 


ammo ctype 
ammo 
ammo 
ammo type 


anno 





SLOAD6 (STO 


WED LOAD 6). Optimal load ammo type 6. 


Bo. TYPE (SYSTEM TYPE). 


TAC1. (TANK 
TAC2. (TANK 
TAC3. (TANK 
TACU. (TANK 
TACS. (TANK 
TAC6. (TANK 

TE 


TANK 


M 


AMMUNITION COD: 


AMMUNITION CODE 2). 


AMMUNITION CODE 3). 


AMMUNITION CODE 4). 


AMMUNITION CODE 5). 


AMMUNITION CODE 6). 


PORARY ENTITIES 


EL 


ROGRAM LISTING 


eas SS 


a 


1 EVENT PIREKILL (A) 
2 DEFINE NO.BATILE,FLAG,TK,PL,DEL, AC,A,1 

3 AS INTEGER VARIABLES 

5S PRINT 1 LINE THUS 

: ,EVENT FIREPOWER KILL CALLED 

7 ‘*CHANGE KILL STATUS TO ELIMINATE THE WEAPON 
8 FROM FURTHER UPDATES 
9 LET MKILL(A) = 1 
10. =O 
1170008 
12 FOR I= 17T0 6, DO 
13 "SET OP ARTIFICIAL DELIVERY 
a7 LET DEL = AMMO1(A) 
13 LET AC = TAC1(A) 
19 re 
20 LET DEL = AMMO2({A) 
21 LET AC = TAC2(A) 
D9, 30 
23 LET DEL = AMMO3(A) 
24 LET AC = TAC3(A) | 
25 eye / 
26 LET DEL = AMMO4(A) 
Dy LET AC = TAC4(A) 
28 roe 
29 LET DEL = AMMOS (A) 
30 LET AC = TACS(A) 
31 16! 
32 LET DEL = AMMO6 (A) 
33 LET AC = TAC6(A) 


woo 
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ce tL ees 


FOR EVERY A IN PLAT.UNIT(PLTLDR), LO 


1 OR MFKILL(A)=1 OR PKILL(A) =1 


OTHERWISE 
IF TAC1(A) =AC 


LET HY (A) =OH t (A) SDBLS (SLOAD1 (A) = OH (A) ))/ 
P. SHORT (PCODE(PLTLDR,AC 
LET AMMO1(A)=ANMOT(A) DEL 
C(SLOAD1 (A) -AMMO1(A)))/ 
P. SHORT (PCODE (PLTLDR, AC) 
GO TO TKLOOP 
|, OTHERWISE 
IF TAC2 (A) 
LET O 2a) =0H2 (A) +DEL‘ SLO AD2 (A) = OH2 (4) ))/ 
SHORT (PCODE (PLTLDR, AC 
LET AMMO2(A) = =annd3 (3) + EL 
SLOAD2 (A) -AMMO2 ad) 2 
>| Co HORT { CODE (PLTLDR, AC) ) 
GO TO TKLOOP 
|, OTHERWISE 
IF TAC3(A)=AC 
LET OH3 (A) =OH3 (A) +DEL¢ (SLOAD3 (A) -OH3(A)))/ 
. SHORT (BCODE (PLTLDR, AC 
LET AMMO3 (A) =AMMO 3 ( (A) + EL 
€ (SLOAD3 (A) -AMMO3 (A))) / 
P SHORT (PCODE (PLTLDR, AC) ) 


GO TO TKLOOP 
OTHERWISE 


IF TACY (A) =AC 
LET OH4 (A) =OH4 (A) +DELC (SLOADY A) 0H OH4 ( (A) 3) / 
Ps SHORT (BCODE (PLTLDR, AC 
LET AMMO4 (A) =AMHO4 (2) +DE 
(S LOAD4 (A) “AMMO (A))) / 
P. SHORT (PCODE (PLTLDR, AC) ) 
GO TO TKLOOP 
OTHERWISE 


IF TACS (A) =aC 
LET OH5 (A) =OHS (A) +DELC (SLOAD 
P.SHORT CODE ( LTLDR,A 
fA) = )-AM 
ODE ( 


+ 


LET AMMOS (A) =AMMOS A)? 
C(SLOADS 
P. SHORT ( 
GO TO TKLOOP 
OTHERWISE 


IF TAC6(A)=AC 
LET O86 (A) =OH6 ( 


A) +D SLOAD6 A) =OH6 (A 
Pas io 
LET AMMO6(A) = AMM 
CSL 
P.S 


EL 
aa PCODE ( LDR AC 


O 
OA 6A) = Auto ¢ A))/ 
HORT (PCODE (PLTLDR, AC) } 


= 


ALWAYS 
'TKLOOP' LOOP 

LOOP 

BOnReoveks TK IN PLAT.UNIP(PLELDR (A)), DO 
Bea te wires (1K) EO 7, 


OTHERWISE 
LET NO.BATTLE = 1 
alone W.AMMO (TK,NO.BATTLE) YIELDING FLAG 
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103 ¢ 

104 CALL P. CLASS. V(PLTLDR (A) ) 
105 RETURN 

106 END 


Line 2-3 Define recursive variables used in the routine. 

Line 5 Prints a message indicating that the routine has 
been called. 

Lines 7-9 Change the kill status of the weapcn system to 
eliminate it rrom further supply computations. 

Line 12 Begins the major loop for the routine, looping over 
the six ammo types carried on a weapon and distributing 
these assets to the other members of the platoon. Loop 
ends on line 95. 

Lines 16-33 Set DEL equal to the amount being taken from 
she damaged weapon and AC equal to its identifying anno 
code. 

Lines 36 Begins an inner loop over the undamaged weapons of 
the platoon in order to distribute the damaged vehicles 
ammo. Loop ends on line 95. 

Lines 37-40 Check the weapon being considered for any 
damage and cycles if damage is determined. 

Lines 43-93 Loop over the six ammo types carried by the 


undamaged weapon to see if it carries the ammo being 
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ieasteoutead from che damaged vehicle. If a match is 
mad2, the amount delivered is equai to the amount being 
+aken from the damaged vehicle times the ratio of the 
weapon's need to the platoon's overail need. 

Line 94 Closes the weapon system loop begun on line 36. 
Control is +ransfertred either to the next weapor or to 
the next ammo. 

Line 95 Closes the ammo loop begun on line 12. Control is 
transferred either to the next ammo type or out. 

Lines 96-102 Cause every weapon system to update its ammo 
Sea Us . 


Line 104 Causes the platoon to update its ammo status. 


INS 
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